Developing software and working on CSS is very similar. The years I have spent developing and supporting our CMS software Perch, turned out to be a far more helpful starting point that you would imagine for life as part of the CSS Working Group.
Nowhere are these similarities more clearly drawn than when it comes to feature requests. I see the following sentiment both in terms of our announcement of a new feature for Perch, or my writing an article about some new part of CSS.
“I can’t see myself ever using that. Why didn’t they work on one of the MANY features I have on my wishlist, instead of this useless thing.”
I understand the frustration of a longed for feature being passed over, and instead something being hailed as useful that I can’t ever see me needing. Yet I wonder how small a world a person must inhabit to believe the only use cases are the ones that they personally have encountered?
The next time you see something and wonder why anyone would need that, instead of telling Twitter what an idiot the software developer (or the CSS Working Group) is, why not follow the use case? Ask questions. Why do people find that useful? What type of projects are they working on? Are they different to the work you do, and how? What problems are they solving with this feature?
Chasing down use cases and understanding the problems that lie beneath them is a vital skill if you ever want to be able to build anything that isn’t only used by people who are exactly like you. When you develop software you will build features you would never use yourself, because other people have use cases that demand it. You may not even like those features, you may feel that the problem ought to be solved elsewhere. Yet you are not where the people who need that thing are, you do not have their constraints, your projects are different. By digging into the problems they are trying to solve you get the privilege of helping to solve them, in the best way possible that will work in the place that those people are.