Why developers play?
Dan Pink in his book Drive! talks about motivation and what drives people to be self-motivated. His three pillars of motivation is autonomy, mastery and purpose. Given all three, participants tend to be in the state of flow, a concept pioneered by Csikszentmihaly. Basically when you're in the flow, your engagement is so high, time is no longer linear or relevant for that matter.
It occurred to me that this is what drives software developers and why we labor for long hours, often forgoing food and sleep in our quest to fix that bug or implement that feature. All the elements Pink talks about are there.
Autonomy. Software developers are pretty autonomous. Generally, there are guiding principles, good software practices and patterns that we abide by. But mostly, software developers are left to their own devices to write the code as they see fit. You define the goals, a feature or bug fix and that's it. Beyond the programming language of choice, we generally do not dictate how the actual code should be written. There lies the creativity. Developers are generally given a destination but seldom told how to get there.
Mastery. Writing software can be considered infinite play. We never stop getting better. The permutations of what can be done is infinite. Of course, as we better, we rely on past libraries, patterns etc to help us get there faster. But the destinations change and we learn along the way by our own mistakes, insights and looking at other people's code. There is always a better way, an opportunity to refactor and perhaps even a different way next time. Mastery gets better but never complete.
Purpose. This is always clear. No developer sets out writing code with no goal in mind. Better still even if the product is extremely large, we learn to break the problem down to small manageable chunks. We narrow it down to a single feature, a bug that needs to be fixed and then we focus our entire energies to achieve that small goal. In short, we learn to create reachable milestones that reinforce our motivation along the way. Each milestone becomes an achievement. The feedback is direct and immediate. It either works or it doesn't.
For many of us, software development is a game even though the deliverables are real. And here is the rub. We often view playing is all fun and no work. No goal and no pain. But truth be told, there is pain. Ask the gamer who battles a boss for 2 days while dying a thousand times. Ask a developer who is frustrated by bad documentation, buggy API or bugs that defy logic. There is defintely pain in play. But here is the point. If you have autonomy, mastery and purpose, you WANT to play even though there is a cost (be in time or mental anguish). You are engaged and self-motivated.
Perhaps software development is the ultimate and infinite playground.
It is Serious Play.
It occurred to me that this is what drives software developers and why we labor for long hours, often forgoing food and sleep in our quest to fix that bug or implement that feature. All the elements Pink talks about are there.
Autonomy. Software developers are pretty autonomous. Generally, there are guiding principles, good software practices and patterns that we abide by. But mostly, software developers are left to their own devices to write the code as they see fit. You define the goals, a feature or bug fix and that's it. Beyond the programming language of choice, we generally do not dictate how the actual code should be written. There lies the creativity. Developers are generally given a destination but seldom told how to get there.
Mastery. Writing software can be considered infinite play. We never stop getting better. The permutations of what can be done is infinite. Of course, as we better, we rely on past libraries, patterns etc to help us get there faster. But the destinations change and we learn along the way by our own mistakes, insights and looking at other people's code. There is always a better way, an opportunity to refactor and perhaps even a different way next time. Mastery gets better but never complete.
Purpose. This is always clear. No developer sets out writing code with no goal in mind. Better still even if the product is extremely large, we learn to break the problem down to small manageable chunks. We narrow it down to a single feature, a bug that needs to be fixed and then we focus our entire energies to achieve that small goal. In short, we learn to create reachable milestones that reinforce our motivation along the way. Each milestone becomes an achievement. The feedback is direct and immediate. It either works or it doesn't.
For many of us, software development is a game even though the deliverables are real. And here is the rub. We often view playing is all fun and no work. No goal and no pain. But truth be told, there is pain. Ask the gamer who battles a boss for 2 days while dying a thousand times. Ask a developer who is frustrated by bad documentation, buggy API or bugs that defy logic. There is defintely pain in play. But here is the point. If you have autonomy, mastery and purpose, you WANT to play even though there is a cost (be in time or mental anguish). You are engaged and self-motivated.
Perhaps software development is the ultimate and infinite playground.
It is Serious Play.
posted by The Idea Dude at 9:00 AM
2 Comments:
I waste most time overcoming fairly minor things and in hindsight would have been more productive by finding another route. However, the problem with programming and technology platforms in general, is that a breakthrough can come in an instant.
Play is an intuitive approach to problem solving that explores various items in the problem space while avoiding the exhaustive, methodical elimination of possibilities.
Theoretically our intuition is weighting the various items to be tested according to convenience, probability, and how many "tests" we can do in a cluster, and how many possibilities can be eliminated.
Play is just an extension of play as a kid, and is best used for solving problems in a space where there are a lot of unknowns. As an accomplished problem solver, I can also tell you its not always the best way, but often the most tempting.
Hi Asher, that's what makes you an accomplished problem solver, the ability to know the balance between process and play.
Post a Comment
<< Home