The Old Blog Archive, 2005-2009

On professionalism

Lately I have been troubled by the attitude that “I do it for free, so take it or leave it”. True that no one should burden the contributor who does it for free. But as such, the contributor should claim no more than having made the contribution. Some “savior” type likes to claim they’re doing an important job, serving many, saving poor souls from X platform, and enjoying the fame. A slightest request, however, results in “I have done so much, platform X sucks, and nothing is for free: write the damn code yourself if you want that feature!” As if the world owes him or her a sorry (enough paean has been sung).

Interestingly how such arrogance can reflect in the code. I’ve seen a few cases where the correlation is high. Legacy features are treated as, well, “legacy”, and are taken away without first understanding why they are there. Variables and functions are named carelessly. No boundary check in place. No real coding style is enforced–both an aesthetic and managing disaster. Dangerous memory copying and pointer arithmatic done in a way that make people who really do K&R frown–and remember? there is no boundary check. All for the sake of the really non-existent problem of “needs to be efficient”. But for those who know better, it’s really just some bricolage in a sorry state.

That’s plain wrong. That I do it for free does not mean I can do it as I wish. Especially if you both claim to be a serious software developer and to have the intention to help others.

It’s like NGOs and charities. That you have good intentions doesn’t relieve you from the responsibility of doing things the right way. That is what professionalism means. Even amateurs know what that means. There are even hobbyist activities that actually require high skill, attention to detail, and utter seriousness.

Some software can be more serious than others. System software is one example. They are not just expected to be reliable. They must be. And tons of application code and logic depend on those foundations. They must be solid as rock. And they need to be very well organized, clear in what they do, and have sound logical flows. And that’s why open source system software projects are run in a serious manner, however disperse and loose their organization is. Coding style is enforced, review and criticism needed, even welcome. Interestingly–individuality still plays important role. Personality clashes can happen. But whatever the argument, reckless coding can be like reckless driving in coding system software.

Serving many can be a tricky business. Or as the saying goes… “With great power comes great responsibility”. Please, please don’t be a savior if you are actually a reckless developer.

Comments are closed.