I have come to dread presentations especially those that involve PowerPoint: this fear has developed over the years mostly due to sitting through way too many terrible presentations.  Here are several trends I have noticed in these painful presentations.

• Reading the slides to the audience.

  This is my number one complaint, most people can read faster than they can talk yet most presenters fall into the trap of reading their slides to their audience.  I read pretty fast, so I am usually finished reading the slide way before the presenter is finished reading the contents of the current slide.  I would rather be emailed the presentation so I could read it myself than have to sit through someone else reading it out to me without any extra embellishment.

• PowerPoint encourages bullet point lists.

  The large text size, overuse of team or corporate logos and stylised templates encourages the use of bullet point lists.  Bullet points list in presentations are terrible as the text size prevents any sort of length or detail.  This means that the information has to be condensed to the point of being almost worthless.

• Lack of hand outs.

  Most presenters don’t give out hand outs: they expect the PowerPoint slide deck to be all the audience requires for future reference on the presentation, most are not even aware of the note feature built into PowerPoint for generating printed hand outs.  If you are giving any sort of technical presentation a handout that is more in depth than the presentation is a must.

• Slide layouts & logos.

  To a lot of presenters it would seem that having a fancy PowerPoint template complete with corporate or team logo is more important than the actual content of their presentation.  I suspect that more time has been spent on the layout and logos of a lot of the presentations I have seen than the actual content.  Which is a disaster as the content is what is going to keep the audience engaged, not some fancy slide template or moving text.

• Lack of pictures.

  You see very little eye candy in most presentations, but having images gives your audience something to look at other than text.  We all know the phrase ‘a picture is worth a thousand words’ yet the content of most presentations is mostly text not images.  This makes no sense as images are one of the most effective tools for the communication of ideas and concepts.

I’d highly recommend reading this brief article which also talks about the pain of PowerPoint usage in particular and recommends a general product recall.  I think a lot of the issues I’ve outlined above about presentations can be traced to the assumption made by most presenters that they are just delivering information: this is false as merely delivering information is not enough.  You must teach your audience the content of your presentation, not throw the information at them and hope it just sticks (it won’t).

Previously I had been using programs like Work Rave and Anti-RSI to make sure I’m taking sufficient work breaks, mostly to keep me sane and free of RSI like injuries (I still recommend these programs).  I confess I am guilty of skipping breaks suggested by these applications fairly frequently, which perhaps is not a smart thing to do as it increases the likelihood of fatigue, injury and lowered productivity.  I had thought this system to be effective but I’m finding puppy breaks even more effective: possibly due to the lack of a skip option.  As puppies with full bladders cannot miss a break without risking an accident!

I think perhaps this lack of a skip option to puppy induced breaks is giving me more of a sense of having to make the most of the time between the breaks, this is helping me focus which results in increased productivity (which is not what I would have expected).  This is a most welcome and unexpected side effect to having the puppies at work with me: aside from the obvious benefits of canine companionship and having a very good excuse to go for a walk at lunch time!

I have found over the years that any sort of regular break gives me a chance to pause and reflect about my current task and that is very useful for considering options and possible solutions to problems.  The end result is that stopping to reflect about what I am currently doing regularly results in a superior end product than just hammering away at a task.

Do you have regular breaks and do they help or hinder your productivity?

I agree teaching a higher level language with built in memory management as a first programming language is the more humane option as far as first time students are concerned.  As learning your first programming language and all the associated concepts is hard enough without all the nasty memory related gotchas in a language like C or C++.  Although the nice thing about learning something like C or php (as Jani suggests) is that teaching object orientation can be avoided initially, as that particular concept does seem to be something that some students struggle with a lot the first time they encounter it.

However I do think a low level language that has manual memory management should be at least experienced by every programmer, as it is a fundamental concept of programming effectively.  And I believe that having minimal experience with some form of manual memory management would help most programmers write higher performance programs.  But perhaps I was being a bit over zealous recommending that everyone learns a language like C/C++ as a first language, although I think at least a short course featuring a language with manual memory management would be invaluable to all programmers.  The course would not even need to cover object orientation as you can teach that in higher level languages that are easier to manipulate than C++: the key point of the course would be to teach memory management and its implications for writing fast high quality software.

As much as I go on about knowing assembler, I admit its not something I write very often at all, however it is something that is incredibly handy to be able to read and comprehend. Even the most basic level of understanding of the instructions for loading data from or to memory and registers, branching and basic math operations would allow you to check the compiler has actually generated the assembly code you expected. This is especially useful for debugging unexpectedly slow code in compiler optimised builds.  You also don’t need to know about all the fancy vendor specific assembly instructions, as I’ve mentioned the basics are usually sufficient to be able to understand roughly what a slow piece of code is doing to then rewrite the higher level source code in a way that prompts compiler to generate faster assembly code.  Actually writing assembly code should always be the last resort and only done by experts after all other higher level refactorings are attempted, as higher level optimisation or refactoring work is usually more effective and easier to understand.  Also, assembler is not usually easily portable to other hardware platforms and most programmers find it harder to debug assembler than normal C/C++ source code.  Plus as Jani mentions it is scary to find a block of inline assembler in the C++ program you are working as it is much harder to decipher than regular source code unless it is very well documented.

This ability to check what is going on ‘under the hood’ of your language is essential for those hard to track down bugs and when optimising your application for performance, especially where the compiler has reordered the program flow or generated unexpectidally slow code. This can also be applied to high level languages as well as C/C++: checking that the IL byte code generated by your C# compiler or the Java byte code generated by the JVM is doing what you expected can be very useful in understanding your program’s execution and performance.

It used to be the case that students would be first taught assembler then a language like C before moving on to a higher level object orientated language like C++ or Java.  Although this was even starting to change when I went to university: the mainstream computer science students were being taught in Java from the start.  Although the course I was on started in C with some assembler plus hardware theory and then onto C++ but this was the exception.  Plus I’d already encountered assembler in high school too, which I’d imagine is no longer the case in high school computing classes today. Talking to the students we have had on placement at work recently, it sounds like C# and Java are now the languages that are mainly being taught.  This means only the theory of memory management and hardware concepts are being taught with no practical experience to reinforce that knowledge.

Why is this a big deal?  Well if a programmer does not understand how the system his high level language is running upon works, how can they then be expected to program that high level language in a way that takes advantage of the available hardware and system architecture?  Or at a minimum avoid the bottlenecks inherent on the particular hardware configuration they are working on?  For example how could they appreciate the potential performance implications of accessing a variable length array vs a fixed length array of structures in a key inner loop if they do not understand how these data types have been implemented in the underlying language libraries or how their underlying hardware system will process it?

Maybe this is something to do with our high performance requirements and that our platforms are closed systems with more finite resources compared to a common PC but we see this sort of thing a lot especially with new software engineers straight out of university.  The lack of understanding of the implications of the performance characteristics of our programming languages and our platform(s) hardware, leads these new software engineers to write code that is not only not as sound as a more senior engineer (which is to be expected) but also with much poorer performance characteristics.

This is not a problem with our students however, it is a problem with how they are taught.  I think part of the reason is that it is harder to teach someone a language like assembler or C or even C++ than a managed language like Java or C#.  As thinking about low level concepts like memory and cache management is not easy and concepts like pointers, memory alignment or functions pointers are not intuitive for many students, so I’d imagine it can be frustrating to teach those classes. And it is easier to teach object orientation in a language like C# or Java than C++ but that mean that we should skip straight to the memory manged high level languages?

So without fundamental knowledge of the basics that experience with lower level languages supply, it is very hard for that student to later write high performance applications without having to go back and learn the basics in their own time.  And I believe writing high performance software is something most software engineers will be required to do even in this Web 2.0 generation.  As anyone who has had to make a website scale to thousands of concurrent users can no doubt atest to the fact that performance is not just for those of us that program the more traditional high performance systems…

I think this trend away from books has been partially brought about by the production and proliferation of books teaching about programming languages and technical issues which date quickly instead of the software engineering principles or design which have a much longer shelf life.  I think this occurred because although at first it was possible for publishers and writers to keep up with the rate of change in programming languages, environments and technologies, it would seem that for the last few years the rate of change has been greater than the publishers could maintain, with a few exceptions.  This has lead to a flooding of the shelves of bookstores with books on version 1 of language X when version 2 is the latest version and on Office 2003 when Office 2007 is now out.  Online sources are much better suited to keep up with the latest news and developments for language/technologies and to provide up to date examples and tutorials. This does not mean books should be ignored but a lot of people seem to be assuming this.

Books that cover subjects like development methodologies, software design, design patterns, problem solving, testing, people management, planning, running teams and other non technology/language specific areas are a vital way to pass on knowledge and information to those new to industry.  However, the increasing trend of relying on online sources is meaning that a lot of new starts in software engineering have not read the classic texts, unless forced to in university.  By not reading these texts they miss out on learning from those that have gone before them and are thus doomed to repeat the mistakes of the past until they learn the hard, slow and inefficient way.

Part of my desire to start this blog was to have on it a recommended reading page, listing the texts I feel every software engineer regardless of platform, language or methodolgy should read in order to ’stand on the shoulders of giants’ and avoid the bane of our discipline which is reinventing the wheel over and over again.  I am currently working on the first pass of my list of recommended reading and hope to have it posted up in the next week or two.

What is the task?

• Describe the task.
• Describe the desired output of the task.

How are you performing the task?

• Describe the steps you take to perform the task.

Could you measure your performance?

• Can you think of a metric that would let you benchmark your performance e.g, time taken.
• Measure (or estimate) using the metric.

What steps are you performing well?

• List the steps you are performing well.

What steps are you not performing well?

• List the steps you are not performing well.

How could you improve your performance?

• List your ideas to improve each step.

Try your improvement ideas.

• List the results of your ideas here, with metrics if possible.

I think that those short development iterations and regular reflection sessions at the end of each iteration introduced by Agile/Scrum are perhaps the two components of these methodologies that help drive process improvement the most, but they are perhaps also the easiest to overlook.  It would seem that the natural inclination for most workers (especially when stressed) is to not stop and think about how they are working, which means they do not truly understand their work flow and this limits their ability to improve their performance.

Some of the most productive individuals I’ve met, or have heard about, are those that regularly take the time to pause and think about how they are working not just about what they are working on and then experiment to improve.  This habit goes against the instinctual urge most of us seem to have when ‘busy’ which is to not stop to think about the how as we think we don’t have the time to spare.  This is a huge misconception, as taking time to pause and think about how we are doing things and how we can improve can yield large gains in terms of increasing productivity and reducing frustration.

Another overlooked aspect of reflection is that it can make a mundane repetitive task more interesting and stimulating by turning it into a personal challenge: can you tune your work flow and improve your performance on a set task?  For example, habit can even be applied to repetitive manual tasks like mowing the lawn: can I mow the loan in a shorter period, where can I save time or remove repetition?

In summary, pausing and reflecting during your working day and then experimenting to improve can help drive a habit of efficiency which will increase your productivity and potentially improve the development process for your whole team, and this is what all development efforts need to suceed.

The next step in note taking is to start using note taking software, I was first introduced to this concept by a co-worker using Omni Outliner on his Apple Powerbook on a project to manage his personal notes and thoughts on his work.  I’ve since started using note taking software in the form of Microsoft OneNote at work, Omni Outliner at home on my iMac and the humble Memo application on my Palm Z22 on the go.  You can even use web based note taking software like Google’s Notebook application.

The features that attracted me to note taking software:

• The ease of organisation possible, its simple to reorganise notes digitally.
• The ability to search through all my notes.
• Copy’n'pasting information in many forms e.g., text, pictures, movies etc directly into my notes.
• The fact I type faster than I can write!
• Built-in spelling and grammar checking.
• I don’t have to worry about losing information due to ink fading or my hand writing being hard to read.

I must admit I’m still a relative novice at using note taking software and I’ve yet to start fully using the more powerful features available. I still tend to write digital notes much like I’d write them in my note book and then tagging the notes as I see fit.  So my notes are more like a personal blog (or PLOG as I like to think of them).  This helps me record and remember my work and those little details I always seem to forget because I only need them every six months.

The next stage of note taking I want to try is to attempt to improve my notes from meetings, which to date have typically just been writing in a note book but I’d like to try recording meetings using a digital voice recorder.  This is not to keep the recordings as evidence but to allow me to make better notes after the meeting, as with a recording I can replay the conversation till I grasp it fully without having to bother anyone.  I’ll be interested to see what the reaction to recording a meeting is, as I guess some folk will be suspicious that I will keep the recording even when I have no intention of doing so.

I’d also like to start getting organised enough to start writing notes for blog posts before I write the actual posts but so far that has not happened.  My dream is to have an Apple Macbook Air so I can have Omni Outliner with me at all times which I think would help a lot rather than having to switch between note applications between home and work.

During university I worked part time as an IT technician, which I think forced me to deal with explaining things to people without technical knowledge of the concept I was explaining. At first I was surprised at how unsuccessful I was at this and that got me thinking about why. Being able to explain something complicated in a manner where someone who has no technical knowledge can understand, is I think a very important skill to have as these sort of explanations will be required often in most sorts of careers.  And often it is those who can communicate most efficiently that succeed more than those that are the most technically proficient, as what use is proficiency or ability if no one can understand you?

The key to becoming good at explanations has a few key parts in my mind:

• Paraphrasing while learning: When learning something new, it is highly beneficial to then paraphrase the new information in your own words.  This practice has two benefits: first you will quickly find out if you understand what you’ve just read and secondly it will get you into the habit of thinking about the information using your own terms rather than just the terms in the texts (which is what you’d be doing if you simply memorised the text).
• Limiting your explanation: If you’re anything like me you’ll want to be as helpful as possible when explaining something, as well as exercise your whole range of knowledge on the topic at hand.  This is actually the worst thing you could do, as if you think back to when you last learned something you’ll most likely realise you didn’t learn the whole subject in one sitting but by digesting it a piece at a time.  When you are explaining something you are effectively teaching, which means someone else is learning and that means you need to keep your explanation short and compact in scope to give your student a hope of remembering it.
• Paraphrasing to verify learning: One of the best ways to check someone has understood your explanation is to ask them to paraphrase it back to you in their own words. This is not easy to do if they are not used to it so be patient; if it takes them a few attempts, they will improve with practice.