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.
- 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.
Eric.weblog() reminded me of an excellent interview with Anders Hejlsberg on generics in C#, Java, and C++. Anders is the kind of person you want in charge of designing a language. In the interview he demonstrates a deep knowledge of the how competing languages implement generics, and the implications of those design decisions. While he is obviously biased towards his own choices, his biases are clearly based in a solid understanding of the alternatives. Matz, the creator of the Ruby language, has a similar grounding; in his communications on the Ruby mailing list he demonstrates an almost encyclopedic knowledge of other programming languages past and present. This contrasts starkly with the attitude I have occasionally seen from certain other language camps (“I don’t know how the other guys do it, but it can’t be better than our way…”).
Eric‘s entire series on moving from C# to Java is worth reading, BTW.
I played around with jQuery a little over the weekend. I’m fairly impressed. The obvious comparison is with Prototype, but I can’t really make that comparison because almost all the Prototype work I’ve done has been automatically generated by Rails. Certainly the code I hand-wrote over the weekend seems more concise and expressive than the generated Prototype code I’ve seen; but part of that may just be an artifact of being handcrafted.
I was going to post some code, but the WordPress editing interface seems to be extremely unfriendly to pasting code snippets.
I attended the Simple Design & Testing Conference over the weekend. A co-worker made me aware of it about two weeks ago, and since it was a) free; b) held at Penn State York, about 20 minutes from my house; and c) had some really smart people like Ron Jeffries on the guest list, I figured I had little excuse not to go.
The format of the conference was all Open Spaces, meaning that it was completely self-organizing conference. This worked out quite well, I thought, and despite having never done anything remotely like this in the past I felt comfortable enough to propose and host two sessions.
Deliver Value on Day 2: I came in about halfway through this one, but I got a lot out of it. I heard the “Strangler Vine” metaphor for the first time, referring to the practice of gradually replacing legacy code with new code until nothing is left of the old. There were also some good points made about how frameworks like Rails can constrain your thinking. For instance, your first step on a project should not necessarily be to create the tables – or even to create the database! Instead of starting with the habitual Rails overhead, just start creating your domain objects and let data persistence be a task for day two.
Questions that drive towards simple design: The goal here was to come up with a list of questions developers ask themselves (or others) which help them to arrive at simple designs. A lot of good content here, like:
- Ask five times “Why?”
- What is the simplest example of doing this sort of thing?
- What is the most catastrophic failure that we need to plan for?
Unobtrusive Confirmation: This was a thought-provoking exploration of humane user interface paradigms. Points included making sane assumptions (but also providing an obvious way to override the assumptions); and providing a way to undo an action instead of asking “Are you sure?”. The conversation grew to encompass a lot of other interesting topics as well.
The two sessions I hosted were:
BDD/RSpec Best Practices: This wound up being more of an intro to RSpec, since most of the attendees had little or no experience with BDD or RSpec.
What are my tests telling me about my design? The idea for this session popped into my head Friday night as I was looking at the wall of proposed topics. I thought it turned out really well. We had a lot of good discussion, and came up with a list of potential test smells that might indicate that there is something sub-optimal about the design. I might write more about the points that emerged when I get a chance. For now, you can see the list we made at the above-linked page.
The conversations were stimulating, I met a bunch of great folks, and the (free!) food was great. All in all it was a fun and productive way to spend a weekend, and I hope I’m able to attend next year’s conference in Chicago.
Only about five years late, here’s my new development blog!