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.