The statements were in many cases intentionally vague. The idea we ended up focusing on was that context is key in many of these things. And, of all the statements that were made, the one that stuck with me the most was:
Programming should be relaxed, care-free and easy.The room was divided on this one, which wasn't uncommon among most of the statements given that we all inferred our own context based on our own experience. This one also generated a good bit of discussion. Time didn't permit very much, though. The basic idea we got out of the discussion was that what we do is difficult by nature and we enjoy challenges and all that good stuff. We don't want things to be stressful, but "easy" just doesn't happen in the real world.
But, at least for me, that didn't really resolve the statement. I still stayed in the "agree" camp. Thinking about it, I keep circling back to a point I shared with the group about how it all depends on how you define your terms. Let's define these ones...
- Relaxed - Well, we can all agree that work shouldn't be stressful. Stress begets poor results. Every good manager knows this, and every programmer wants to work for a good manager. Sure, sometimes stress happens. Sometimes deadlines are tight. But, honestly, that's what managers are for. If a project is unrealistically managed and the stress of it trickles down to the developers, then the project is in danger. The developers should be relaxed.
- Care-free - I can see how this one can have a lot of different meanings to a lot of different people. At first one may picture a kind of hippie-like carelessness to the world around you. This, of course, isn't a good approach to programming. My interpretation was a little different. When I think "care-free" I'm reminded of an instruction given to the American during a sparring match in The Last Samurai:
"Mind the sword, mind the people watch, mind enemy - too many mind"This is where the developer should be. He shouldn't have external cares pressing him while he's working. His team (manager, project manager, tech lead, etc.) should keep those things out of the way. The developer should be able to remove these external influences and work in a care-free, worry-free environment. The work being produced by the developer is the only concern. If that work has value to the company, then the environment which produces that work has value to the company.
- Easy - This was the one that most people didn't like. Again, it's a matter of definition. Easy is the opposite of difficult, that's easy. But at the same time, difficult is not the same thing as challenging. I certainly agree with the overall opinion that what we do is by its nature challenging. It's interesting, it requires intelligence and focus. However, just because what we do is challenging doesn't mean it's also supposed to be difficult. That's a cop-out for people who don't want to make it easy. Making it easy takes effort, it takes time, it takes work. But the result is that it should be easy in the sense that it should be enjoyable. This goes back to the "relaxed" bit earlier. The job itself is challenging, but the act of going to work and doing the job should be easy.
Programming should be relaxed, care-free and easy.