I’ve been thinking a lot about the subject of professionalism in the context of software development lately. As I see it, there are two strains of professionalism. There are, for lack of a better term, “professionalistic” developers. To be professionalistic is to adopt the trappings of professionalism while missing out on the underlying attitude. These are the developers who know all the acronyms and buzzwords and will happily tell their managers when asked that they are “87.3% complete” on their current project.
Then there is the other kind, the true professionals. I don’t feel I have a good enough handle on the topic to distill what it means to be professional down to a few pithy phrases. But I “know it when I see it”, as the saying goes. I can begin to describe it by example.
Professionalism is…
- Understanding that software is hard, but that the hardest problems you face are social, not technical, and do not have technical solutions.
- Rewriting the cleverest, most difficult code you’ve written until it appears so trivial that any idiot could have written it.
- Asking your colleagues for feedback even when you are sure that you are right.
- Answering emails as soon as you get them, even if it’s just to say “I don’t have time to look at this right now”.
- Explaining a solution in simple terms, even when you know all the buzzwords and academic terms for it. And even when you’re certain that your audience ought to know those terms.
- Evaluating every potential change in terms of business value and risk as well as elegance and programmer happiness.
- Proving your point with code and statistics, rather than rhetoric.
- Not spending hours writing code and collecting statistics, just for the sake of proving a point.
- Asking questions even when you think you know the answer.
- Investing constantly in your knowledge portfolio, whether your job forces you to or not.
- Going out of your way to help n00bs, without behaving as if it’s a chore.
- Researching alternatives, but time-boxing your research. Forcing yourself to stop at the end of the allotted time even though you are oh so close to the perfect solution.
- Joining your coworkers for lunch periodically.
- Following, contributing, or taking charge, rather than arguing.
- Discarding your faith in your own gut-level estimates, and measuring your performance empirically. Then adjusting your estimates accordingly.
- Rigidly controlling the scope of changes. Resisting the urge to rewrite for the sake of rewriting.
- Reporting actual project status,not what you think your manager wants to hear.
- Thinking of the customer as a an asset, not an enemy.
- Recognizing that you are not only fallible, but probably overlooking something vital at this very moment.
- Not expecting the world to fall neatly into categories, systems, and procedures the way code does.
- Keeping your perspective.
- Staying organized. It doesn’t matter so much what system you use, whether you’re a Franklin-Covey type or a GTD nerd or just keep copious notes in a spiral-bound notebook. Knowing what you were doing yesterday, what you are doing right now, and what responsibilities are currently on your plate is one of the true marks of a professional.
- Turning off your workstation and going home at the end of the work day, whether the problem is solved yet or not.
I’m sure I could think of many others, if I kept at it. I’m no paragon; I’ve been guilty of violating all of these. Some of them I still violate on a regular basis. Part of my goal in writing this list is to take a look at my own comportment and as a developer and discover where I am falling short.
