I had a kind of epiphany about “figuring out” a solution to a problem versus “making” a solution to a problem. Let’s break out the two a little bit just so I’m not rambling to the world without some context.
What I stumbled into thought about is the “figuring out” a solution is done when there is not solution that is currently known. Figuring out the problem, knowing it intimately, then through a bit of analysis and possibly discussion a solution is found to a problem.
With the concept of “making” I had the idea that a solution exists, someone is assigned the problem, and then the solution is then applied to the problem.
These two ideals kind of struck me as a division of labor compared to a scientific labor. One is a matter of planning and training, the other is a matter of empirical knowledge and application of scientific principal to resolve a problem. Of course, in software development often the scientific principal is nothing more than a barrage of trial and error processes strung together.
One of the things that I wanted to do as soon as I was struck by my epiphany was segment people into the respective two concepts. After some more thought though, I realized, that no one specifically fits into one or the other type of concept. Someone might fit more into a “figuring out” paradigm more than a “making” solution thought process, but a person might have to wear both hats, or change back and forth during the course of a career.
There is however the application of these conceptual task delineations that could be made of particular tasks within a problem. Let’s compare a game production company versus building an enterprise application.
To provide example take a look at a game production company. There are many problems there that haven’t been resolved. There are crude inroads to certain tasks, but for the most part the game development process is done via the “figuring out” solution method.
On the other side of this scenario is the enterprise application expertise. Most of the problems that need resolved in enterprise development need nothing more than a “making” the solution expert. The enterprise environment has been thoroughly thought about in many aspects and entire suites of tools and software are available. There is of course the “business problem” that could require a bit of “figuring out” solution approaches, but the core of enterprise development is practically a tried and true art now.
I’m done with my little epiphany now and am heading to a day full of intense unit, integration, and general test coding. Cheers!
