Here’s a common scenario: you are out with some former co-workers and one of them asks if you know someone you could recommend for a project they are starting. Beyond the obvious technology or skill matching, what’s the main basis on which you would recommend someone?
For most of us it will be something about their attitude, specifically having a positive one, making them good to work with. People who are positive and enthusiastic make dealing with the inevitable vicissitudes of project life bearable.

But if things were that simple, putting together a project team would be nothing more than a case of cracking a few jokes, selecting anyone who laughs and kicking out all the moody buggers. And it’s not. It’s also not as simple as saying we like to be around permanently happy people. On software projects we usually value how positivity helps us make better decisions. For example, faced with a horrendously complicated problem, we can either panic and hope a third party product will solve it, or calmly (positively) break the problem down and look for simple solutions to each aspect of it.

Positive attitude = Clean Thinking = Better Software

The relationship works the other way too. Working with well-designed software helps us to think clearly about how to add new features easily. If we can do that it makes us feel good. This is because of what sociologists call reflexivity: we make valuable progress on behalf of our clients quickly, which makes us feel good, so we address the next set of problems with a better attitude and come up with better solutions, which help make valuable progress. A positive-feedback-driven virtuous circle. Good software makes people (and their clients) happy. Conversely, complex tools and programming languages introduce interference that gets between project teams and their goals.

Here is a snippet of Java that prints “Hello, World” on the screen when it’s run:

And here’s the same thing in Python:

Which one has the most interference?
This is not a Java bashing. In fact, for serious distributed systems development, the  alternative to many other languages would be far easier to look after. It’s relative. Happiness comes from having the minimum impedance between what you want to do and being able to do it. Some things you want to do will be complicated and require a bit of thought (and a robust framework underneath). Making complex things seem too easy is a dangerous game, as the Law of Leaky Abstractions reminds us. If you want to explore the vast differences in how programming languages address something as simple as printing “Hello, World,” Wolfram Rösler keeps a very big list.

The Ruby programming language even had happiness baked into its design. Yukihiro “Matz” Matsumoto, the creator of Ruby, said “I hope to see Ruby help every programmer in the world to be productive, and to enjoy programming, and to be happy. That is the primary purpose of Ruby language.” Happy how? By reducing the friction between thinking about what you want to do and doing it, reflexively. The psychologist Mihály Csíkszentmihályi called this reflexive state “flow”.
Flow is when, given a goal and your first step towards achieving it, you:

– experience immediate and useful feedback
– feel that your next step will take you closer to success
– are so caught up in this loop that everything else in the world feels temporarily superfluous.

Programmers also call this being in the zone and dislike being interrupted when they are in. And of course it’s not limited to programming. We’ve all experienced flow when working on a gratifying task. In “Predicting Flow at Work”, Karina Nielsen and Bryan Cleal suggest that flow may even be good for our health. Their paper, published in the Journal of Occupational Health Psychology in April 2010, examined work activities to see which ones promoted flow and which ones didn’t. Interestingly, brainstorming sessions did not create a flow-like feeling of well-being, probably because we don’t get immediate feedback and, as they themselves state, we don’t feel “in control of the situation.” What does promote flow is: planning, problem solving and evaluation where we are “engaged in cognitively challenging activities.”

Brainstorming’s inability to engender mental serenity in us is perhaps not surprising. Brainstorming sessions are essentially just another form of meeting and much has been written about why meetings are an energy-sapping waste of time. Yet most of us would agree that some meetings are necessary: knowledge sharing, communication, cross-team collaboration can all be effectively achieved via a short targeted meeting. And these meetings don’t have to break our state of flow, rather they give us the fuel to get back to our desks and experience it.

Brainstorming’s inability to engender mental serenity in us is perhaps not surprising.

Alas, many meetings are not short or targeted, and many are generated by the sort of aimlessness that arises when there’s no collective agreement on how to proceed. These kind of meetings do break flow. Nobody leaves with a clear goal and the virtuous cycle is broken and put in reverse, which makes them bad for our wellbeing and unhelpful in cultivating a positive attitude, thus ultimately bad for our clients. Problem solving, even in a group, is good but only when backed up by purpose, feedback and the conviction that the problem is solvable, making programming languages, frameworks and third party products that frustrate us, even slightly, as toxic as pointless meetings.

Is there a lesson here?
Well there are two actually. In the cold light of financial analysis, projects are about turning money into value. The efficiency with which we execute that alchemy is almost entirely down to how quickly we can get things done, and that in turn depends on our attitude: to think clearly, not get overwhelmed and to make good choices.

So the obvious lesson is to choose happy people and keep those people happy by letting them select the tools that work for them. Allow them to generate their own states of flow and to create that circle of positive reinforcement.
The other is a little more nuanced. Too many meetings can be a sign of poor project management. But it can also be a sign of inappropriate technology choices. When meetings do take place they should be about the problem space, not about daunting tasks created by the technology. Or even about the technology at all.

Software problems do sometimes get so big they can’t be sorted out by a couple of developers sitting at a desk, but if that happens a lot then it may be sign the tech is taking over the project. If that’s true there will be little room for flow and the chances of delivering a happy client will be reduced.

The good news is this can be dealt with – use regular project retrospectives to check for flow. If the team are not feeling it, and there’s a sense too many meetings are being held hostage by the software stack, then change it. Spike something different and win the flow back.
The short amount of time lost to this will be more than repaid by a fresh and reinvigorated team, faster progress and a happier client.