The Internet is full of “10 Rules For Effective Meetings” blog posts so why not create my own? Sure, why not?

These are the guidelines I try to follow when organizing meetings. They work fine for me in the context of the company I work for (flat structure, ~80 people, no managers, no corpo-bullshit). I have no idea what happens if you apply them to your workplace (but I bet, it would be something positive).

 

Meetings People Love

Meetings People Love

A Meeting? Seriously?

Sometimes it is enough to visit your colleague in the next room, sometimes all you need is a short discussion on group chat with few people, sometimes simply wait till certain people are having coffee break and join them for a five minutes discussion.

Meeting is a heavy, time-consuming, corpo-smelling, commonly disliked thing – look for a lighter solution.

Save People’s Time

As an organizer make sure you do everything possible to save people’s time. This means you make sure that:

  • all important people will show up,
  • the room is ready (see below),
  • all participants  know what they should prepare for the meeting (if anything), and that they really did,
  • lead the meeting so that it is worth being there

One minute of your preparations can result in few minutes saved for each participant. Do the math.

Organize the Room

Always be there at least 5 minutes before the meeting. This gives you time to reorganize tables and chairs, tweak the air conditioning, bring missing markers, clean the whiteboard, check the projector works etc. Make sure the flip chart, markers, magnets, pencils, cards, or whatever else you gonna use is there.

They way the tables and chairs are organized is important. Make sure you know what type of meeting you want (a lecture? an open discussion?) and put the chairs so that people have no choice but sit according to your plan. If it doesn’t work just like that, ask people to rearrange so they sit the way you intended. Really, do it. If not, you will end up with weak discussion only because people sit side by side and can’t really talk to each other. Or you will have two hostile tribes on two other sides of the table. And it will be your fault.

Action Points

A meeting without Action Points (AP) is a waste of time. Make sure everyone knows what was decided (remind them right before the end of the meeting). Every AP should have an owner. For every AP it should be clear what the next step is, and when this next step should be finished.

Meeting Notes

Keep them short – usually the APs is all that matters. Add pictures of whiteboards notes, sketches, diagrams etc. – a good reminder of what happened during the meeting.

Send the notes ASAP (to all interested parties) after the meeting is finished.

Make Fun of It

If possible make some fun around the meeting. Yes, do it. The invitation can be funny or you can put some funny accents into the meeting notes. I’m trying to do it for (some) meetings I run at Codewise and I think it works. From discussions with my colleagues I suspect some of them take look at the notes because they want to find out what kind of stupid stuff I put there among serious notes. Good! – at least they will scan through the notes looking for hidden gems and will inhale some of the essence (if they want it or not).

I will give you one example of what I’m talking about. This is an email invitation to developers to take part in our weekly “devs meeting” – which is a gathering of interested individuals from each development team to share business and technology news. So usually the invitation email is “standard”, but from time to time, I try to tweak it a little bit. For example, like this:

meeting_code_monkeys

Facts First

For problem-solving meetings always start with the facts. Even if you think people know the full picture. They usually don’t. It is your task to learn about it before the meeting, and then present it in a concise way. Or – even better – ask the participants to list them. If not, you risk all kind of misunderstandings (like people discussing different issues, while thinking they all talk about the same).

OK, here comes a story. So once upon a time we had this meeting. And I explicitly asked participants beforehand to prepare a list of facts so we start discussion with them. Once the meeting started one person gave like one fact and immediately followed with a general solution, which, in his opinion, solved all problems related to the discussed topic! I stopped him in the middle of a sentence and refused to discuss the solution until we learn about the whole picture. We continued with the facts and listed 12 of them on a whiteboard. After 30 minutes of a discussion we agreed on some action points. The solutions we discovered were completely different from what the first guy suggested. I would also say they were much better. Can you guess why?

Do Not Distract People

Do not turn on the projector too early, and make sure you switch it off when it is not needed anymore. For some reason, people will stare at the screen even if nothing happens there (instead taking part in the discussion).

Switch off all communicators/calendar reminders when presenting. First, it distracts people. Second, it can be pretty embarrassing. 🙂

Transparency

For problem-solving meetings always leave the door open. Invite crucial people and let other know that such and such meeting will be held. And don’t worry – only few (if any!) will come. But those who decide to join you will probably have something interesting to say. Good for you, right?

Similarly, publish the notes so that all employees can read them. You have nothing to hide, do you?

As Attendee

  • Come prepared. If asked to read something, read it. If asked to think about some idea beforehand, think about the idea. Simple, isn’t it?
  • Don’t attend a meeting if you do not feel like going there. Your absent-presence won’t help anyone.
  • Think about other people who could help and discuss inviting them with the meeting host.
  • Always inform the organizers if you attend or not. A simple click in the calendar is all they need – and it really helps them to prepare a meeting.

Tips & Tricks

  • If we chit-chat instead of discussing it means the meeting is over. Finish it.
  • For recurring meetings, change the meeting host once in a while. It helps to fight the boredom.
  • Throw away empty markers immediately. Have no mercy!

Ending Quote

For all programmers out there, who love all kind of meetings 🙂

delete_emails_and_avoid_meetings

I remember some time ago I was really excited about the idea of soft assertions. The latest blog post by Rafał Borowiec reminded me about them. …but wait, if I was so crazy about them some time ago, then how it happened that now I need to be reminded about their existence?

So first of all, I believe they make sense only for integration or e2e tests. Only, where execution of test is so costly (in terms of time) that you really, really want to learn as much about the tested scenario as possible. So, if you have a long (Webdriver) test, which ends with bunch of asserts, then I think it might make sense to write them using soft assertions.

But for unit tests? Oh no, you do not need soft asserts! Execution of such test takes milliseconds so rerunning them is simply a matter of few keystrokes using your IDE. Not much gained by soft asserts here.
And I also see a potential downside. I think that using soft asserts might lead you into the wrong direction: it might encourage you to verify much more then required, or to verify different thing “because you can”. No, thank you, I strongly believe you should go with one (logical!) assertion per test.

So, all in all, my initial excitement about the soft assertions has vanished over the years. I would never use them for unit tests, and I do not use them for other kind of tests. Why not? I think that when I first learned about them they were not supported by the tools so I gave up the idea. And later… well, I think I got used to not using them, and as I think now about my E2E/GUI/Integration tests I do not see compelling reasons to change my mind.

Just my 3 cents.

We all know that rubber duck is programmer’s best friend (it was also proven that such duck should be yellow for maximum effect). Not surprisingly I have also a yellow toy on my desk. But it is not a duck. It is a little yellow human-like figure.

Usually it sits and waits for me to start explaining some code. It waits patiently till I get to the aha! moment. Sometimes it waits long. But it never gets bored. From time to time I can see it’s smile widens when I explain the nuances of my-oh-so-perfect-and-surely-working code.

2015_09_yellow_static

But that is something which every rubber duck can do for you. My yellow friend has one hidden superpower which makes it much more useful. Look at the next image. Awesome, isn’t it?!

2015_09_yellow_hold

See? When I take my laptop home my yellow friend makes sure next time I come to the office I won’t have to dive under my desk to catch the cables. Cool, isn’t it?

Few days ago I learned a very simple, yet powerful trick which saved me some time. To make long story short, it happened on a test environment shared between few projects.

I deployed a new version of one application there, and after some time received emails with errors. Uh-oh, apparently I have broken something! Hmm… but what really happened? The stacktrace hasn’t really enlightened me in any way… Hmm…. But you know what? The entity that was printed out in the exception message looked like this:
User{email='john.kowalski.somerandomstuff@whatever.com}

And it happened that John Kowalski was my colleague working on a different team (but using the same test environment). To solve the mystery of “why-oh-why-it-does-not-work-all-tests-are-green-for-gods-sake” all I had to do was to have a short chat with him. It appeared that he was running some IT-tests which were using some incomplete data (at least from my point of view), well, it doesn’t really matter. The thing is, that thanks to him signing his work, I was able to solve my problem pretty fast.

So don’t be shy about your IT/E2E test. Sign them, and maybe someone will be thankful for this.

And BTW if you would like to learn more about writing high-quality tests then check my Bad Tests, Good Tests book.

From time to time it is good to see what are the latest versions of the libraries you use (because maybe you would like to upgrade). You can use the Versions Maven Plugin like this:


mvn versions:display-dependency-updates versions:display-plugin-updates

but the output is too verbose. And for multi-module project you will get flooded with same information about each module (cause if you use not-the-latest version of e.g. JUnit, then it will be reported for each sub-module).

In order to make your life easier you better create a bash alias (~/.bash_aliases) like this:


alias mver="mvn versions:display-dependency-updates
 versions:display-plugin-updates | grep 'INFO' | grep '>' | sort |
 uniq"

and then after you run it, you will see something similar to the following output:


[INFO] cglib:cglib ............................................... 2.2 -> 3.1
[INFO] com.googlecode.flyway:flyway-core ..................... 2.0.3 -> 2.3.1
[INFO] com.google.guava:guava ................................ 16.0.1 -> 18.0
[INFO] javax.mail:mail ................................... 1.4.7 -> 1.5.0-b01
[INFO] org.aspectj:aspectjweaver ............................. 1.7.3 -> 1.8.2
[INFO] org.springframework:spring-webmvc ..... 4.0.6.RELEASE -> 4.1.0.RELEASE
[INFO] xml-apis:xml-apis .................................... 1.4.01 -> 2.0.2

There is still some room for improvement but it works good enough for me. I hope you will find it useful as well.

Cheers!

It amazes me how many great tools you can find on the web! In this post I describe 4 of them. I hope you find them useful.

Decode and Encode Base64

I know it is only a line of two of coding, but this comes quite handy when you need to decode/encode base64 stuff: http://decodebase64.com/. Copy & Paste and get results. Voila!
text_decode64

JSON Editor Online

New to JSON? If so, you will be happy to try out JSON Editor Online. Look at the screenshot below:

text_json_editor_online

See? Two panes, with source code and structure tree. Very nice to analyze JSON snippets or experiment with JSON syntax.

AsciiFlow

Ever wanted to draw diagrams? I bet! The thing is that many tools can now convert simple ascii-art diagrams into nice looking images. Take for example Asciidoctor. Pretty cool, isn’t it?

So, the thing is you can create such ascii-art diagrams without any pain using the AsciiFlow tool. Try it out.

text_asciiflow

PlantText

Plant Text harnesses power of Plant UML to create various diagrams.
text_plaintext_while

I also used this tool for rapid prototyping of UI. Yeah, I know there are much more powerful tools for this, but sometime PlantText is all I need.
text_plaintext_gui