Before you set out, you need a destination, a goal. A goal needs to be measurable, that is, you need a way to confirm that you have achieved it. When driving, that usually means arriving at the specified coordinates. Additionally, you may want to get there within no more than 40 minutes.

Once you know where you are going, you need a general route. In business, it is called a strategy. You don’t need to know every turn in advance. Conditions may change: traffic, construction or other unforseen circumstances that may slow you down or prevent you from getting to your destination. That is why your strategy usually goes like this: go west, then south, and use highways to save time and gas. In business, those in control of the resources pick the strategy. A strategy is long-term and should not change much. That is why it needs to be very general, without specifics.

Once you set out, you will be making tactical decisions. Which street is best to get to the highway? Which streets to avoid? Field experts are the best people for that. They know traffic patterns based on time of the day or time of the year. They are aware of sporting events and which streets are affected. They know where the construction sites are. They know traffic lights, speed limits and other road signs that may have an impact. Tactics are specific actions. They are short-term decisions that follow the strategy in order to best accomplish a goal.

Now go, drive safely and efficiently to your destination.

Without hesitation, developers of that product reacted. They were outraged, saying that the budget was entirely justified due to the complexity of the project. The fact that they felt targeted at all is a bad sign, because we certainly didn’t set out to lay blame. To deny that anything at all could have been done better is a lie to oneself and to the client. Have you ever finished a project thinking how things could have gone better? Hopefully you always do. I have been in the field since 1997 and I still improve.

So why would a developer fervently defend a ridiculous budget and what does it mean to the company?

Such a reaction is mostly due to an inflated ego. Everyone likes to think that their project is ultra-complex, the hardest thing ever built. But complexity is relative to one’s experience. An information system built on PHP with a mobile app on top is hardly worth 40 million unless a lot of the money was spent unwisely, in one way or another.

Regardless of what caused the project to blow out of proportion, the fact that people would defend such a big budget should alarm the company. What it means is that these developers would gladly use up all of the company’s resources if they could justify it. It means that they’re too good to have done anything better. It means that they would turn down expert advice even if it meant saving a lot of money for their client.

Why not save money? After a quick research into the names of the developers who replied, it turns out that they are all contractors, not employees. Indeed, longer projects gives them job security. Should an expert come in and find ways to cut production time in half, they would be looking for a new “job” sooner. Not all contractors act this way, but these clearly don’t have their client’s best interests at heart.

That does not mean that companies should not hire contractors. It means that it’s always better to have an expert on board who can see problems before they happen and who can save the company some 20 million or more. Don’t ignore your ROI. Don’t be the John Carter of IT.

How did I become a speaker? Credit goes partially to Chris Shiflett. He didn’t realize what he has done when he casually asked me why I didn’t submit to a conference yet. That was in 2006 or 2007, I can’t recall. I gave the typical response, that I didn’t feel that I was good enough. He told me not to worry and that I’ll do just fine. And you know what? I went and submitted to a few conferences, got rejected, swallowed my pride and tried again. I eventually spoke in France, Canada, USA and Germany. What I have learned from this experience is that speaking never came to my mind until someone suggested it. So go ahead, suggest it. Tell them that it’s not so hard. Tell them to try at a user group or even at lunch in their company. Some people may not like public speaking and you shouldn’t pressure them or make them feel guilty for not speaking.

The second story is about my growing up. I have always loved technology and science. My parents never agreed with me on anything. Not on my choice of toys (lego and remote controlled cars), not on my choice of friends (boys who climb trees and roofs), not on my activities (video games and sci-fi series) and not on my choice of career (programming). I didn’t care what they wanted for me. I decided on my career all by myself at the age of 11. The fact that it was an unconventional career for a woman didn’t even cross my mind. I was passionate. That’s all that should ever matter. Passion. Not gender.

At work, I was a token. This is the main reason why the “we need more women speakers” speech triggers such a response. Every time that a client visited the company or a new employee was hired, management would stop at my desk and point out that I was a woman. It sometimes felt like being a freak in a circus. It was unpleasant to be seen as something other than a skilled programmer. I once turned down a job offer because they really wanted to have a woman among their 40 male developers. I immediately thought of other candidates who will be turned down merely because they were male. The decision process seemed unfair. My sense of justice could not allow that, so I removed myself from the equation and gave all these men a fair chance.

And so every time that a conference asks for more women to submit, I am reminded of that job interview. Since having more women is a clear objective, then all decisions have to be weighed against it. Sure, we all want to think that we are not biased, but we are. As soon as we make something our mission, it inevitably affects our decisions. For me, conferences have nothing to do with gender. Gender is irrelevant. We’re here to talk about technology. When presented with two proposals on the same topic, I hope that a woman would not automatically win because someone wants to see a pie chart with equal slices. That is not what equal opportunity means. I am a woman, and I don’t want unfair advantages.

Do we really need to turn gender distribution into a problem? How exactly will the world be a better place with more women speakers? It’s just a number in a spreadsheet that some choose to find annoying. I’ll tell you what’s really annoying: people not automating tests, people withholding information about threats to projects, people not indexing their database tables or over-indexing them, people not using any cache, people skipping software analysis and design, etc. These are the beast that we need to slay. The rest is just a distraction, ready to suck all our time and deviate us from the path to knowledge and collaboration. When you review my application, please consider my skills, my character and the relevance of the topic for your audience. Don’t worry about my gender.

Functional Tests

Think of it as testing your application in the browser, but in an automated fashion. There are many ways to automate. Some tools can go as far as launch a specific browser and programmatically simulate user input, other tools can take a step back and send appropriate HTTP requests while inspecting the HTTP response.

In order to perform these, you do not need to know how the software is implemented. They are very high level tests. All you need to know is what the software is expected to do. For example, when you enter an invalid phone number and submit the form, the form should reload with an error message on top of the page. If the form saves at this point, you know that you have a problem, possibly in your validation or the validation may have been skipped. You know the general location of the problem, now you just have to dive into the code.

Functional tests will always prove useful and can do things that others cannot. For example, I use functional testing to simulate a sequence of user actions. Here is a simple scenario, written in natural language for your benefit:

1. Authenticate a user that has only reading permissions.
2. Navigate to an article’s draft.
3. Assert that the status code is 404.
4. Assert that the page contains a link to the most recently published article.
5. Click the link and wait for the page to load.
6. Assert that the status code is 200.
7. Assert that the title of the article is correct.

There is almost no limit to what you can verify with functional tests. The more assertions you write, the easier it will be to pinpoint the location of a potential bug.

Unit Tests

Unit tests are low level tests. They are meant to test your code rather than the high-level features. You need to have an understanding of how the code works and how the functions are linked. For example, you could have a method called canOpenArticle which will take a user and an article argument. Based on the permissions of the user and the status of the article, the function would return true or false. You expect specific output based on the input. Examples:

1. Call canOpenArticle with a reader and a draft article.
2. The output should be false.

1. Call canOpenArticle with an author and a draft article.
2. The output should be true.

User tests should operate on a single function or a small group of functions to be most effective. This will allow you to pinpoint the exact location of the issue. If you mix too many of your application functions in one test case, it will be much harder to tell which one of them is at fault when that test case fails. More on this in my next article: “The Missing Intro to Unit Tests”.

Integration Tests

There are many definitions to this floating around. To avoid overlap with other tests, I define this as the testing of self-contained modules that you expect to be working on their own. All you want to do is make sure that you use them correctly. For example, if you’re using the Google Maps API, you don’t expect it to have bugs. Yes, it’s possible that they have bugs, but for the sake of sanity and good practices, your responsibility should stop here. You want to make sure that you are using the API correctly, that’s all. When I write integration tests, I send parameters to the API and expect the output to be exactly as documented. If it doesn’t match, I first assume that I’m using it wrong. Did I forget a parameter? Did I send a date in the wrong format? Did I misspel something? Once all my integration tests pass, I expect the API to keep behaving. If the API changes without telling me, I’ll know pretty quickly with my tests and will fix my API calls accordingly.

Here are some more examples of integration tests: framework, plugins, libraries, payment gateway, etc. For some of them you may have access to the code, for others you can’t see the code. In any case, always treat these as black boxes and focus your integration tests on the communication between your software and these external components. Bonus: you can do something similar between your own modules for better decoupling, so that each module could be swapped as long as it uses the same communication protocol.

Now go and try all of these. Don’t favor one over the other, as they are all meant to work together like a seat belt and an airbag. You wouldn’t trust your safety to only one of these, right?

Tip: try to test the smallest unit possible, usually a function, rather than a combination of functions. Testing combinations is called integration testing, which I will cover in subsequent posts.

Here are a few easy to spot opportunities for writing unit tests.

When you encounter bugs.

• Find the exact location of the bug.
• Write a test that will not pass while the bug is present, but should pass once the bug is fixed.
• Run the test and confirm that it fails.
• Apply the bug fix.
• Run the test and confirm that it now passes.

The test ensures that this bug doesn’t resurface later, when you make unrelated changes to your code.

When you improve existing code.

• Write tests for the function that you are about to change.
• Make changes.
• Run the tests again.

The test ensures that your functions still work as expected and that you have not introduced new bugs.

When you first write the code.

• Every time you output something to make sure that your code behaves as expected, write a quick test instead.
• As you write more of them, run all the tests, not just the last one you added.

Before you write the code.

• Once you decide to write a function, think about its input and output.
• Write tests for the input and expected output.
• All your tests should fail at this time, because the function doesn’t exist yet or is blank.
• Start implementing the function.
• Run tests frequently until all of them pass.

The better tests you write, the less chance that you event introduce a bug. More than that, your function will probably be shorter and clearer, because you only wrote minimal code to satisfy expectations (tests). These tests may also uncover design flaws before you’re too advanced into the code.

As you increase the number of tests, you will increase your confidence in the code and will be able to make more daring changes.

See how we gradually went from crisis management to TDD? It’s easy once you have a clear path to follow. Learn more by signing up for my next workshop “Testing by Example”.

Planning is often overlooked, whether you write software, blog posts, books or presentations. I started this post by making a list of things to say, rearranging the items and removing less important ones to make the whole thing short. For presentations, I cut my production time from 40 hours to only 20 hours by planning with mind maps. That’s because you spend time on content rather than form. By all means, do plan before you open your presentation software.

I once attended an incredible workshop where the speaker only used 6 slides in 6 hours. Don’t assume that your audience has a dog’s attention span or that they can’t understand what you say without visual support. People are smart, so treat them as such. Five words per slide is great, but when you end up flicking every 20 seconds to compensate, the audience gets distracted. A little faster and they may get seizures. If you’re going to say it anyway, why write it on your slides? Slides are for showing things that cannot be communicated effectively in words.

Avoid writing code on slides when you can, use short snippets otherwise. I recommend using images and diagrams rather than text whenever possible. Just don’t pick overly abstract pictures as that is also distracting. Here’s an example to show device compatibility that is both more effective and more appealing than a bullet-point. Create a separate deck of slides for publishing online as a reference, if you must.

When you begin speaking, introduce yourself and why people should listen to your advice. Position yourself as an expert on the topic. Don’t spend more than a minute on that. Then, instead of a table of contents, tell your audience what to expect, and what not to expect. Example:

“I will give you a general understanding of how to profile queries, how to pick good indexes, how to write better queries and give you a checklist to try against your current projects.”

I strongly recommend splitting your talks into self-contained chapters. Each break allows for questions from the audience, making your talks a lot more interactive. Chapters also make your talks easier to follow, as opposed to talks where every concept is built on top of a previous concept, and everything could collapse should an attendee misunderstand an element along the journey.

If find that stories and metaphors are very effective communication tools. Use them as much as possible. People come to you for your experience, not to hear something that they can read in a manual.

This concludes my brief list of ideas to improve your presentations. Try out a few of them that you find interesting. Don’t use the ones that you don’t like.

Think of  a developer as an athlete. He or she is aiming for a medal in a competition. A figure skater can’t just perform a triple axel in the Olympics after seeing it done on television. This requires a lot of practice, so that when the time comes, the performance is flawless.

Of course, programming doesn’t have to be flawless. One must remain pragmatic, yet it still requires practice before a concept can be safely implemented without breaking the project or missing deadlines. Who will pay for that practice?

Let’s go back to our athletes. In case of a team, it’s the manager’s job to secure funding. So a team is basically an employer, that allocates much time for practice between the matches. There’s no point in sending a team with a play if they only saw it once on paper.

Now let’s translate that into IT. Work is divided into projects and then further into iterations, depending on your methodology. Say you have a two-week iteration at the end of which you must deliver a fixed number of features. How many days can a developer afford to try various solutions before settling on the one? Two or three days don’t sound like much. Let developers poke around, see if the newly acquired concepts are applicable and then focus on delivering the features for the remaining duration. If a concept works, great. If not, better luck next time.

I also recommend to use any idle time between projects to practice some more. Perhaps try out new languages, frameworks or even implement a prototype for something that has nothing to do with any project. This is also known as R&D and many countries have credits for that. The thing about R&D is that failure should always be an option. You can’t afford to fail during a project. Therefore, you must allocate time for it in a way that won’t hurt the project.

Developers need a sandbox. If you don’t give it to them, you can end up with one of the following issues. Your entire project could become a sandbox, making it unstable. Developers will be forced to practice at home, making them unhappy at work and eventually quit. Worse, innovation in your company could stall once developers become tired of fighting the management.

If you want your developers to get better, allow time for practice, not just learning. It’s necessary, easy to do when planned and provides countless benefits to your company. Let me know how that advice worked out for you.

The event is at the Hilton Bonaventure Montreal, from February 25th to March 1st. Tickets are sold online.

We are also looking for students who wish to volunteer for the event.

Assumptions vs Prejudice

We always make assumptions based on our past experience. Examples include: an elementary teacher is a woman, a mechanic is a man, a person with an expensive camera is a photographer. This is different from prejudice where you make an opinion not based on experience or evidence. Examples include: girls suck at math, girls can’t be gamers and blondes are dumb. There is absolutely no evidence to support these claims.

Now back to the clothing.

Geek Uniform

Why do women feel compelled to wear geeky t-shirts over womanly clothes?

Many geeks, whether male or female, wear the geek uniform. That usually consists of jeans and a black or grey t-shirt with a reference to programming, video games, science or a sci-fi show. It’s like a competition of geekness. Another popular attire is a black or grey sweater. The audience of a conference often looks like a computer terminal: a dark background with a few colors in the foreground. You won’t be any less geek if you wear an orange shirt. Colors are soooooo much more fun.

The Male Stereotype

What happens to the man who decides to wear a nice shirt? Think about his job……………….. You might have thought about management or sales. Geeks are expected to wear more casual clothes. Geeks don’t dress up. But do geeks wear a Tesla t-shirt when they go to a high school reunion? I would assume not.

The Female Stereotype

What happens to the woman who decides to wear a dress? Think about her job……………….. You might have thought about PR or marketing. She may even be a booth babe if she’s really pretty. And so, to avoid being mislabelled, some women put on a dull t-shirt and lose their identity.

It’s not so hard to say “actually, I’m a programmer”. BOOM! It feels great, try it. Tell them what you do for a living. Until then, all they can do is guess based on past experience. In their experience, they may have never met a woman who can program. Cut them some slack.

I am a Geek

Or at least that’s what my friends say. “You’re such a geek, it’s unbelievable”.

Assumptions used to annoy me, but now I’m actually enjoying seeing men’s faces when they discover that I’m a skilled programmer, that I like sci-fi, action movies and video games. I impress people with my big photo lens when I bring it along. But then they sometimes mistake me for a photographer

When I wear a dress at a conference, other women tell me that they wish they had put their dress. It’s contagious, so spread it! Here is some inspiration. Sorry I couldn’t find a photo of me with the dress. Men are hesitant to take my pic because they’re afraid to look like stalkers.

Tip #1: Advisors

Purpose

The purpose of advisors is to select better content for the conference. No matter how skilled we are, we are limited by our experience and points of view. Other people will bring a touch of variety and new expertise to the table. We have been operating in a bubble for many years, and received feedback that our content was getting repetitive, for example.

We also wanted the process to be as transparent and fair as possible. Having community members question our process helps refine it and make it more just. This is encouraging for speakers since they know that people with different backgrounds and opinions looked at their proposals. More about this in an upcoming post about the selection process.

Finally, having an increasing number of proposals made it increasingly difficult to take the time to evaluate each one. We didn’t want to take 6 months to choose the talks or skim through the titles for buzzwords. We wanted to give every proposal the attention it deserves. Just for perspective, we went from over 500 proposals last year to nearly 800 this year. With 16 advisors to help us, we picked 160 amazing talks.

Choosing Advisors

Our advisors included speakers, due to their experience with the subjects but also because they attend a lot of conferences. This makes them knowledgeable about what presentations work best and possibly familiar with many proposals.

We also invited community leaders and active community members. They follow the trends, meet a lot of people and are generally involved in various projects. If they host presentations, they are likely also have seen many speakers and their skills. The two advisor types complement each other very well.

We selected multiple advisors for each theme: JavaScript, Ruby, PHP, etc. This allows for them to challenge each other to get the best results. It also helps motivation because people don’t sit in their own silo: they can discuss the proposals and share their top-n lists.

Setting Expectations

To incorrectly set expectations may result in disappointment. Before you list tasks, make sure you describe the conference, its goals and its values. A good preparation is important before you reach out to advisors.

A clear list of tasks enables everybody to know exactly what they are signing up for. More on this further down.

Be honest about the expected time that advisors may have to put in. In our case, we estimated 5 hours per week, which was more or less an accurate prediction. It’s better to have somebody say “no” than setting false expectations and ruin a relationship.

Advisors must be qualified in their domain to pick useful topics and be pleasant to work with. Choose advisors according to the level of the content that you want to provide and to the atmosphere that you want to create. When somebody is not a team player, it quickly generates frustration. Although a good communicator can mend bridges.

List the mutual advantages that each party gets. Our advantages for advisors include: the power to build a track, visibility for the technology, reinforcing a personal brand and a free ticket for ConFoo. Notice that there is no money involved, as we believe that it will suck the fun out of the process.

Finally, responsibilities and accountability must be very clear. What will happen if there aren’t enough proposals to make a viable track? What happens if somebody decides to withdraw late in the process? These problems came up numerous times and were unpleasant to deal with. Signing a paper to express commitment will be our solution for next year, because people don’t always mean what they say. Not a contract with liabilities and such, but an agreement. That means that the rules must be very clear before we begin the race, so that people don’t feel forced to do something unexpected.

Tasks

Our task list consisted of three items. First advisors need to search for speakers to get enough proposals for a viable track. Give a hand and share advice. Also, have a contingency plan. In our case, we would rather not have a track than make it too small or of low quality, as it would have the effect of disappointing the audience and make things harder next year. We started posting about the upcoming call for papers 3 weeks before the opening, to give the news a chance to propagate in the networks, so that people stay alert or even begin preparing proposals.

Next, they need to perform the selection to create a balanced track that fits with the overall conference content. That involves reading the proposals, discussing with other advisors and come up with a selection. Next year, we hope to devise a system for writing official selection reasons rather than mixed user comments. It was a titanesque task before advisors, but now that we no longer need to spend time on writing processes and collaboration tools, it looks promising. This will be great news to speakers.

Finally, advisors need to promote the conference. Ticket sales pay for the speakers’ expenses, such as a flight, a stay at the hotel, breakfast, hot lunch, coffee (2600 cups last year), etc. We consider it to be part of the mutual advantages with advisors. They have extensive networks and a few words here and there require little effort. We don’t expect any number of sales, just a hand in promotion.

The timeline for the tasks must be set in advance. Advisors are already busy and need to schedule for this extra work. Also, this avoids unexpected deadlines that are impossible to meet.

Communication

We used doodle.com to pick the best day of the week for work sessions. These were scheduled through the call for papers and selection, for a total of 7 meetings. At my office, each week, we started with pizza, drinks and a few off-topic conversations to get in the mood. Then, we would read the proposals that were submitted so far, write comments and discuss with the team. It was a mix of quiet work and conversations. Some advisors were not in Montreal and so joined us on IRC. We used Skype too, but next year we will centralize everything on IRC.

At any time, an advisor could send questions and top-n lists on the advisor mailing list for discussion. Since some of these discussions were not relevant to all advisors because they were unfamiliar with the technology, we are considering a sub-list for some tracks so that people feel more at ease with multiple exchanges. I was personally responsible for sending weekly reminders, advice, raising warning flags and celebrating successes.

I was always available to answer the phone with advice, to answer questions or even just to chat. It is important to have an open channel of communication at all times. The inclusion of advisors was a priority for me. I hope that they can say that they felt welcome, respected and empowered. Any mistakes that we made in the process, we will correct.

That’s it for now!

Enjoy this advice and add more in the comments. If you provide any examples of what not to do, please don’t mention events and names to avoid making organizers feel bad, even if it’s a commercial event. You can just e-mail them privately.

Some of the following posts will cover the public call for papers and the selection process.