The two sides of testing team lead Jonathan Patchell.

At daily standup meetings, they eye each other from opposite sides of the room. Sitting on the same side of the cubicle wall is unthinkable.

They’re united only by their desire to produce quality software products and their appreciation for coffee and energy drinks. What’s good to one side can be anathema to the other when it comes to code.

I’m talking, of course, about testing and development teams. In the interests of generating more comments improving dialogue between two very important functions in a software organization, our marketing director asked me to interview our testing team lead, Jonathan Patchell, about the ways in which developers drive his team nuts.

Patchell, a computer systems engineer, has been with Klocwork for five years and a team lead for two. He struck a fairly conciliatory tone for this interview, which sorta ruins the adversarial approach, but don’t let his diplomacy fool you. I’ve seen him suffering as the release date approaches and his demeanour changes completely.

Here are Patchell’s top dev peeves:

It was a mistake for Eric to wear a t-shirt to his job interview, and it was a bigger mistake to wear that particular t-shirt.

People who do not get hired after an interview second guess themselves; they look for concrete reasons as to why they were not hired for that particular job.  They might justify it by saying the company sucked, the interviewer was an HR douchebag, the hiring manager did not know their stuff.  Of course, they may be correct in passing these judgments, however, chances are there simply was a mismatch between the person interviewing and the company.  When this happens, count your blessings that the people doing the interviewing for the company knew that.  Being brought into a company that is a mismatch with your values and attitudes can impact everything you do, not to mention, make you downright miserable.

An interview is an opportunity for you to interview the company…to find out if you like them.  It is not just about sitting in front of some scary people and answering the questions they fire at you.   For most people, interviews are not pleasant experiences.  However, they are an evil necessity, until a more effective way of assessing people is invented.  And this brings me to the point of this blog…how the hell do you get through an interview?

1. Be prepared, know the names of the interviewers, know the company business and feel free to bring in notes.  It is entirely reasonable to request more information from the company representative setting up the interview.
2. Appear enthusiastic and interested (but not so much that you are confused with a salesperson!).
3. Dress appropriately.  This generally means clean trousers and a shirt with a collar, maybe a tie for the men, a clean skirt and a blouse for the women.
4. Answer the questions, and if you do not know the answer, let the interviewer know with the promise to get back to them.
5. ASK QUESTIONS…find out enough information to determine whether you want to be an employee.
6. Finally, follow up…if you like what you heard during the interview.  Just an e-mail will suffice, and believe me that will set you apart from 90% of the candidates.

There I have said it. As a marketer, I am disappointed in my peers in their attempts to get their message in the hands of their audience.  Over the past couple of weeks, I have attended a few webinars from other organizations selling software development tools that were truly atrocious.  So here are a few pointers for my few marketers on webinars:

• Stop talking down to the audience – treating your prospects as unintelligent blobs is not the way to connect or be heard. These people are senior developers and engineering managers of Fortune 500 companies not kids coming out of school. Yes, there is a need to bring everyone up to speed and get them to the same knowledge level but that can be done in the first few minutes; don’t do it throughout the presentation.

• Slideware hell:
  • Have a congruent theme – pick one major point and each and every slide in the rest of the presentation should support that theme. Don’t over complicate it.
  • Don’t read your slides – I can read too;  I don’t need you to do that.  I need you to tell me why your point is important so that I pay attention and expand into examples and facts that prove your point.
  • Don’t cram every possible benefit on to a slide – this goes with the previous point – at most 4 bullet points – highlight what is important and use your oratory skills to expand
  • Balance your text with meaningful visuals – I am going to scan your slide in 10 seconds and then turn my brain off. So to keep my attention, give me a visual containing information not just data and each slide needs to tell me something new

• Don’t try to garner respect, earn it. Don’t tell me in your previous life you shared their pain; it comes off as false. Product Managers, you especially  have been the ones at fault for this one.  I am not attending to hear about you. I have a problem; I am looking for a solution.

• Respect their time: webinars are a great vehicle to communicate with an audience but don’t overdo it.  I personally don’t sign up to webinars that last an hour.  I am not willing to give you that much of my time and I would hazard to say neither does most of the potential audience.  Check your abandonment or engagement rates.

Enough ranting and berating of my fellow marketers but together we have to get better at what we do.

Have just stumbled across the lamda module in boost (popular C++ general-purpose library known for extensive usage of templates and influence on C++ standard committee).

A quote:

The primary motivation for the BLL (Boost Lambda Library) is to provide flexible and convenient means to define unnamed function objects for STL algorithms …

for_each(a.begin(), a.end(), std::cout << _1 << ' ');

My first thought was: "Hmm ... a macro?" It appears it is not. The <code>_1 object is a lambda placeholder, and should be read as first parameter of lambda expression (a.k.a. unnamed function). In fact the std::cout << _1 << ' ' expression is automatically converted into a function-like object, that can be used with most STL algorithms (like for_each, find_if, etc.) So, instead of writing this (a traditional STL way): template <typename T> struct my_printer : public std::unary_function<void, T> {      void operator()(const T &x)      { std::cout << x << ‘ ‘; } }; // … for_each(a.begin(), a.end(), my_printer<my_element_type>());

You can use the above expression, and C++ compiler automatically creates anonymous class that represents an unnamed function. The trick is that all this "behind-the-scene" work is expressed in terms of C++ templates and heavily relies on automatic type inference, and operator overloading. Essentially the module has to overload every possible C++ operator that can be applied to the lambda placeholder, "delay" the evaluation of expression and "wrap" the computation into a callable object.

This approach apparently simulates Lisp lambda expressions (hence the name of the module) and Smalltalk/Ruby code blocks:

a do: [ :⁣x | Transcript show: x; show: ' ' ]

a.each { |x| print x, " " }

(for-each (lambda (x) (display x) (display " ")) a)

Lambda expressions and code blocks are essential part of these languages and one of the things that make them consistent and fun to use. Now, this library is trying to adopt this concept into C++.

Pretty cool, but the following limitations lead me to think that this C++ implementation of lambda expressions is far from complete:

• Boost lambda expressions are not true closures (you can not refer to "non-local" data from the block)
• Some operators (most notably "." and assignment) can not be overloaded this way, so i = _1 and _1.my_field does not work and requires some extra C++ tricks
• Can not use statements in this kind of code blocks, works only with expressions
• If you make a simple mistake in this kind of lambda-expression (or change some related interface), the C++ compiler will gladly present you with a pile of human-unreadable error messages with about a dozen template instantiations with names that do not fit a line of text (no matter how wide your LCD panel is), using each other ... that's a common problem of all non-trivial template libraries

After all, this demonstrates that C++ templates and type inference are indeed powerful concepts, but still not powerful enough to redefine/extend the language in consistent way.

Another problem with this kind of smart C++ tricks is that it creates an illusion of simplicity. As always with C++ - you can not rely on this simplicity, unless you know the details of what's under the hood. If you dare to ignore implementation details you risk losing control over your own code one day.