Home → 2004/03/09, 20h51
Understanding the domain, and enjoying it
From the latest post on the BileBlog:
So come on people, if your job is boring, please accept that and try to find fulfilment elsewhere. Do not write a framework or seek the approval of other tossers in your field. Find some other, more private, way of coping. There are plenty of ways to find fulfilment that do not involve using the latest 'cool' library.
Ok, so I have to admit it: I have been reading the BileBlog in secret for some time now. But his latest post deserves that I get out of the closet. It is on a subject I wanted to talk about and despite his writing style, I kind of agree with him on this subject.
If I go back to the days I joined Corel on the CorelDraw suite team, developers were enjoying their work: invent new ways to draw on a computer. The domain was the theory of 2D graphics. The cool thing was to see a complex shape take form on the screen using a mouse and clicking here and there. Developers were excited to work on this product because what was being built was cool. During these years, building a common reusable set of components was not important. Implementing a fast rendering engine was important. Figure out how users could draw curves with a mouse was important.
Today, software is in every domain. From accounting to robots that take photos on Mars. Take the robots for example: what do you think NASA developers cared about when building the software that drives the 2 computerized photographers up there? Using the latest technology? Building a framework so it is easier to build other robots for other planets, other surfaces? I doubt it. I believe their head was filled with the images of their pet strolling on the red sand.
Now, take a developer working on the implementation of an application in a domain that is of no interest to him, a domain where everything is known in advance. The technology used to build the application becomes the center of interest. Then, the temptation is high to figure out ways to introduce a new 'cool' technology, or even better, to create a framework that will be appreciated and used by other developers.
My point: as a developer, if I want to (1) be useful to my employer/client and (2) enjoy my work, I must understand the domain of the application I am building and enjoy it enough to become creative with it.