28 May 2013

Course reflections

Last week I hold my second internal company course, Coding standards and behaviors, with focus to make my colleagues more interested into the topic. In the end all attended had to give feedback on the course and it resulted in the image below.

Feedback from the course Coding standards and behaviors
And now some reflections...

The target group

The course was open for all who was interested to learn more about the topic. In the invitation I had included an agenda to reach the right target better. I do believe I did well with the invitation. I don't only want to have geeks in the audience.  I do know that the discussion get better when people have different backgrounds. Also, I get better feedback.

My preparations

I started with a pre-study about the course content 2 months before the actual presentation date and started preparing the PowerPoint presentation about 1,5 week ahead. During the first phase I tried to read and collect as much information as possible, e.g. documents, books and blogs. I tried to summaries everything in headings. The second and last phase was about sorting the important and most interesting parts into slides. This is the hard bit!

What I aimed for

The main focus was to make people more interested in writing safer code and using coding standards and coding style, as a help to achieve it. Also by being aware about strange behaviors (undefined and unspecified) in language, like C, are also helpful. I tried to have simple example but I also added a few more complex, with purpose to show how hard it is to understand some parts.

Was it appreciated?

This one is the tricky part, but I do believe it was based on three facts:

  1. All the seats were filled the same day the course as announced
  2. The picture above shove that most of the attendees marked it above average on the interest scale
  3. I received some personal and positive feedback afterwards.
Because the target group was quit wide I expected some feedback were people thought it be not so interested or it wasn’t what I had expected. The questions are:

  • Can I do anything about it?
    Yes, by a) more précised target group and b) more detailed agenda.
  • Should I do anything about it?
    It depends. If I am asked to hold the same course once more I will probably update the course description. But in the same time I want to keep the content a little bit open, especially if it’s something new I have to do research in.

Why do I teach?

Because it’s fun! I also learn more about the subject when I need to teach it.

Some tips if you want to hold a presentation

If you haven’t held a presentation before, you should now that creating good informative slides take really long time. First of all you have to define two things:

  1. What is your story?
  2. How is the target?
The first one is a help for planning. Do you know everything already today? Or do you have to do a lot of research first? It also helps you to stick to the plan. The second one decides on what technical level you should have on your presentation. Is it a Java for dummies or advance cache optimization. If the target group is more senior, you should be prepared for trickier questions. They can even tell you that you are wrong :-)

When you finally start with the art of creating slides, here are some general tips:

  • Stick to short and few sentences
  • Pictures are nice
  • Verify your colors on a project screen.
  • Font size. can the person in the back read it?
  • Style consistency. The layout should be similar between the slides
  • Add questions (as a reminder for you to wake up the audience:-) )
  • Avoid preaching
  • Add some extra energy on the start end slide

02 May 2013

How much shall I refactor?

"disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior"
-       Martin Fowler

Usually refactoring is initialized by code smell, a piece of code that does what I shall do, but doesn’t look “good”. But it can be initialized by several other reasons and some of them are:

Readability – a code part is really complex and the context it’s in would be easier to understand if it’s replaced with a function. For example, calculating the mean value of an array:

Testability – by replace some part of the code with a function, writing test gets so much easier to do. The code you want to test is depending on a previous part and you need to control the output from it.

Reusability – by extracting and generalize some part of the code, it can be re-used in several other parts.

So whats the point with this post? What I listed above is nothing new. It has been said and written of thousands of people.

A few days ago I watched a video from Öredev with Oren Eini, Hard Coding - A Design Approach. The most interesting he points out is that after Gang Of Four released  Design Patterns, we have refactored and abstract code into so many layers that the code gets more complex and difficult to understand. Without good documentation and/or someone describing to you what the code actually does, time-to-understand-was-this-code-does has increased.

I don’t say that Design Patterns are bad. I like them. I use them. I do believe that they should be used with caution.

Back to the first question, how much shall I refactor? 

As long as the code gets easier to read, test and modify, you should always consider refactoring, but check that your performance don't gets worse.

KISS – Keep It Simple, Stupid!