You can provide a couple of facts and maybe your audience will remember then. But the important part is to instill the hunger for more as well as providing the resources to learn more.

This is pretty obvious true for short calls to action. But I think this is even true for highly technical, rather lengthy talks. Even for workshops.

Imagine you are attending a one day workshop for a new programming language. There is no way you really understand that language in one day. But what you can expect is: To understand some basic ideas. To feel why it is worth learning this language. And a bunch of links, videos and books to learn more about it.

If you try to be complete you’ll end up with something that sounds like the public reading of a Language Specification. Nobody wants to hear that.

The easy answer is: Join the local x User Group, where x is your preferred programming language. But what to do if there is no such User Group.

You don’t have to go to expensive trainings (although those help sometimes). In many cases all you need is a little time for research and a couple of like minded people for mutual support. Meet once a month. Do a coding Dojo. Discuss what you have learned form an article or a book. Do code reviews. Invite local bloggers for talks. Create a page in Facebook and/or LinkedIn (or Xing if you are from Germany). Invite everybody remotely interested in the topic to join. Talk to the people that come to your meetings.

Ask companies, your employer, if they would sponsor the meetings, by providing a room and a beamer.

Thats it. You just started a User Group. It really isn’t that difficult. And you will learn a lot on the way. About the topic of the user group, about interesting people around you and about organizing stuff.

If you are really interested in joining a User Group there will be one in your city. Possibly founded by yourself.

Why it isn’t perfect:

• It’s bound to Amazon. Everything in the kindle is geared to buy from Amazon and to be bound to Amazon the content is encumbered with Amazons DRM. This isn’t much of a problem right now, but I don’t like that situation a bit.
• It’s not an iPad. Don’t get me wrong, I’m not much interested in an iPad. If I would win won, I would be happy to sell it and to buy books for the money, but It would be cool if the kindle would have the fast color display, touchscreen and a sensor to tell it its orientation in space.

But the kindle is awesome because it is the perfect gadget for the purpose for which I bought it: Reading.

• The kindle is small and light. You can hold it for a long time in one hand, e.g. while walking. Try that with an iPad.
• It has a display that is so paper like that I actually thought it would be a piece of paper I had to pull of before using the kindle when I unwrapped it. You can read in in bright sunlight at an angle at which a normal computer screen would act like a mirror
• You can put it to the side for 5 seconds or 5 days without worrying about the page you where reading. Great if you want to read near kids who ask a question approximately every 12.57 seconds.
• Kindle books are cheap. This might confuse you because a lot of people complain that Kindle books are only a little cheaper than hard covers and more expensive than paper back editions. But if you buy English books at Amazon.de you pay the american price for the kindle book which is in many cases way cheaper than the German book price.

One complain you often here is that the handling of PDFs and other document formats is bad. Well it depends on what you expect. PDF is a page oriented format without any semantic information. For example a footnote is just a piece of text inside PDF an in no way tied to the place where the footnote is referenced. If you convert such a format to the kindle format you get some not so nice effects, but it was absolutely usable in about half a dozen cases where I tried it. If the layout is to complex, possibly with tables and graphics you can read PDF directly without converting it, which works ok, when holding the Kindle sideways. It will enlarge the PDF so the width fills the screen. And ‘turning the page’ will actually scroll down the page in about two steps before actually proceeding to the next page. Again not perfect, but absolutely usable.

So if you read a lot and are interested in English Tech Books or old Classics (which are often free) chances are you want a Kindle.

Hardly anything will change because you complain.

Hardly anybody will change becaus you complain.

It doesn’t make you feel better.

Instead of complaining focus on what YOU can change.

Changing stuff actually changes things (Surprise)!

Changing stuff has the power to change people!

Letting change happen feels good.

Letting change happen gives you the power to change even more.

There are two difficulties when trying to change:

First is finding the right scope of change. You might just not be able to bring peace to the world. But YOU CAN change the way YOU interact with people. YOU CAN teach people how to solve a problem YOU solved.

You can’t convert a big ball of mud in a nice clean code base in an afternoon. But YOU CAN write a test. YOU CAN pair with a coworker in order to learn and teach.YOU CAN leave the code base a little cleaner then you found it. YOU CAN start a group of people with common interest in your company, in your town, in your country.

The other difficult part is starting. Not just thinking ‘somebody should …’ or ‘I could …’ but doing it. There is a simple solution to this:

START NOW!

Yet I see lots of software developer who don’t seem to have a sketch pad. If you are one of those, you should change that NOW. This doesn’t mean you have buy one of these old fashioned paper things. For our profession there are other (possibly better) alternatives:

Your phone: It probably has some way of keeping notes. Heck you can even record audio if you like. This is perfect for making sure you have it available at at all times.

Groupware: Outlook for example has ‘notes’ where you can type (or copy) bits of text. As usual you can create folders and search for notes.

Google Docs: You can have multiple documents, different types of documents, you can share them … oh … and of course you can search them

Dropbox syncs a folder on your various PCs (or Macs or whatever) automatically in the background. You can create and edit documents any time on any machine and as soon as an internet connection becomes available it gets synchronized with the storage on the web. And every other machine gets the new version as soon as they are on the net. Works like a charm and is free for amounts of data that should suffice for almost all sketchpad. I like dropbox because it doesn’t limit you in the formats you use. For example I sometimes feel like collecting some ideas as a mind map. In such a case I put that mind map in my dropbox.

A wiki: If you have your own webspace you might be able to setup a wiki, which is at least for me the best option, since you can easily arrange your content and link between and to it.

I personally use a media wiki instance as my main sketchpad and use all the other stuff for special purposes.

As so often the technical solution is the simple part. The important part is getting into the habit of using it. So what should you put into your sketchpad? Of course it is really up to you to decide but you should put there everything you might be interested in later. This probably includes

Code Snippets: Cool solutions of a problem, examples of API usage, scripts.

Links to interesting articles, forum questions of which the answers are interesting or important

Ideas of things you want to do or to try or explore.

What ever you put in your sketchpad, make sure you put some note to it, what it is good for. Otherwise you might end up with tons of snippets of which you have no idea what they do. Not very helpful. It also eases searching in your sketchpad.

In any case it is better to put to much in it then not enough, so in case of doubt put it in. This also helps in the beginning to get in the habit of using your sketchpad.

Of course there is a second kind of usage to it. Its not doing much good if you only put stuff in. You should also refer to your sketchpad for the stuff you put in there. For this it helps when you organize your sketchpad in a way that makes you see other parts of it when putting new content in. So don’t make your notes / chapters / articles to short, but keep multiple stuff on one page. You also might go through your sketchpad occasionally to clean it up, to add some notes and to review whats in there.

So if you don’t have a sketchpad start one now. If you have one, let us know where it is and what kind of stuff is in there.

Presentation Zen Design: Simple Design Principles and Techniques to Enhance Your Presentations (Voices That Matter) is the follow up on Presentation Zen: Simple Ideas on Presentation Design and Delivery (Voices That Matter) which I loved and which changed the way I do presentations. While Presentation Zen is one extremely important book for me, Presentation Zen Design was a little weak. A lot of stuff I already knew, plus to much on the design side which I can’t apply. Not a bad book but not really for me.

How Would You Move Mount Fuji?: Microsoft’s Cult of the Puzzle — How the World’s Smartest Companies Select the Most Creative Thinkers is a fun read about the interview questions they supposedly ask at microsoft and other places. As a preparation for such interview it is probably pretty useless, but it is fun to read, especially when you like logic puzzles.

Domain Specific Languages (Addison-Wesley Signature) by Martin Fowler. As often with books by Fowler there is not much an experienced developer doesn’t know yet or can’t find in other books. BUT he once again assembles a complete set of patterns, describes them and gives names to them. While this doesn’t sound like much it helps a lot in evalutating your options when considering a DSL. I also learned a lot about parsing, lexing and so on. Good book. Must Read.

Test Driven Development. By Example (Addison-Wesley Signature) is a great introduction into TDD. If you are not practicing TDD yet, you should read this. But if you already read another book about that topic, you might skip this one.

Drive: The Surprising Truth About What Motivates Us is simply a great book. It showed me a lot of things that motivate me, which is great because now I can at least to some extend use that knowledge to improve my life. I also recommend this book for everyone who is or wants to be the boss of someone. If you really can’t read the book, here is my personal essence from it: Bonuses don’t work. Read the book if you want to know why.

Lean Software Development: An Agile Toolkit for Software Development Managers is one of the many books I read about lean and agile and stuff. Its good. Its written by the Popendieks which shows. I especially liked the chapter about the effect of contract design on the relationship between supplier and customer.

Don’t Make Me Think!: A Common Sense Approach to Web Usability a guide to pragmatic user interface design. It’s simple. It’s easy to read and it even shows how to do actual usability testing when you are one a tight budget.

Extreme Programming Explained: Embrace Change adds what is missing in many books about agile software development: practices of solid, high quality software development (as opposed to practices revolving around the organization of work). When you want to learn about agile, this is one of the two books you need to read as a developer.

Agile Software Development with Scrum is the other book you must read when you are interested in agile. While it is focused on Scrum, it does a great job in explaining why scrum works the way it is. This is helpful no matter what method you use.

Getting Things Done. The Art of Stress-Free Productivity shows simple little process that will lead you to higher productivity. At least it did that to me. While my productivity isn’t nearly where I would like it to be, I at least know the things to tweak in order to get better. Must read when you are constantly feel like you day needs at least three extra hours.

Programming in Scala … well the readers of my blog noticed, that I’m fooling around with scala a lot lately. This is one reason and the foundation of my fooling. It’s a good book, although I have to admit I don’t know other Scala books yet, so I can’t make a comparison.

Structure and Interpretation of Computer Programs (Mit Electrical Engineering and Computer Science Series) is possibly the most interesting read during the last year and I’m actually not finished yet. This book gets either great or awful revisions at amazon. The reason is simple: It’s not an easy read. It is not easily applicable. The chances of direct application of your new skills in the job are extremely slim. BUT no matter how much programming and software development you did, if you read this book you will learn a lot. For example you will learn how much you can do in a language without using assignement. And you will only notice this on page 200 something when assignment is introduced. So I am absolutely on the 5 star side of this book. Must read for everybody who really wants to push his understanding of programming and programming languages.

So that is my (not complete) list of the somewhat IT related books I read during the last 12 months. There where lots of helpful books in the list. I hope it will be the same during the next 12 months. Ok I’ll head over to amazon and order another book. Enjoy the new year.

But a commenter answered that presentations after to much learning and preparation look stiff and like theater. I didn’t get that. It never happened for me. What was he talking about?

By now I think I can guess what the commenter was referring to. If you ‘learn’ your presentation by memorizing exactly what you want to say, how you want to say it, how you want to move the result probably will look stiff.

Don’t do that to your audience. Don’t memorize your material! Memorizing is plain wrong.

Instead understand your material. Know your message. Know your own feelings about that message.

If your slides include a number that you can’t remember without actively  memorizing it, that number is not important to you. If it is not important to you, you won’t be able to convince the audience about it’s importance.

Maybe the number is not important, but it’s size, or it’s relation to a different number. If that is the part that is important to you, you will have no problem showing that during your talk.

You want you company to head in a new direction? Envision yourself two years in that direction. How do you feel about that? Now envision yourself two years in the alternative direction. How does that feel?

Now show your audience your feelings. If you are emotional about a subject you will find the words and they will be way more convincing than any well crafted, memorized speech.

It still helps to practice your talk, but that is more for fine tuning your slides to your emotions, not the other way round

The good news is: Every kid learns it. You can tell the parents of kids that just learned it from the blood dripping from their ears.

The bad news is: Almost everybody unlearns it during their time in school. So you might have to relearn it. Here is what you have to do:

The next time you are in a meeting or in the audience of a conference talk and don’t grasp what somebody else is talking about, look around and do the following estimate:

• 10% of the people are actually understood everything. They will be glad when somebody asks because it will show how smart they are.
• 50% are asleep anyway and don’t care what is happening, as long as they can sleep a little longer.
• 40% are just as clueless as you are but haven’t read this blog, so they don’t dare to ask.
• The speaker will be glad, because everybody asking a question was obviously awake during the talk, which is some kind of positive feedback.

So everybody will be better of . Tell me again, why aren’t you asking your question?

By the way: Just last week we had a small internal conference at LINEAS for all employees with talks by various employees. We also had Jurgen Appelo as a key note speaker, and he gave his talk at the local scrum user group the evening before as well. I am proud to say, I was kind of responsible for getting Jurgen over to Braunschweig.

Rumors say people where wondering “How did Jens pull that of?” Easy: I asked.

When I am stuck with a problem my escalation strategy works more or less like this:

• ask the coworker right next to me
• ask Google, Stackoverflow, specialized forums (including bug databases and issue trackers) or twitter (Kent Beck answered twice when I complained about JUnit problems on twitter, and I wasn’t even asking for help).
• ask specialists I happen to know. E.g. the administrators of my employer LINEAS for system/OS problems, a close friend for Unix and Scrum issues, a former coworker for scripting problems, a different former coworker for management questions and so on.
• ask a specialist that I happen to know a twitter account of.

I can’t remember a single instance when anybody reacted negative on being addressed with a question. Just one requirement: Put some work in your question. Make sure you read the manual, asked Google and the FAQ. Make sure this shows in the question. And don’t demand help. Ask for it.

So, think about it, who is on your lifeline?

If you push towards change,

If you don’t give up,

If you try over and over again,

If you try different approaches,

If you talk to everyone who lets you talk,

someday change will happen no matter what your official title is.

Be persistent if the cause is worth it.