Nick Bradbury left a comment on my previous entry saying that he believes all developers should spend time in support – it reminded me that I haven’t really posted about what happens when a developer starts at Ephox.
Aside from the fact that we have a new developer in support rotation, it’s been a long-standing policy that all developers who start with us spend at least their first month or two in support. It not only gives them a good grounding in the more arcane features of our product as well as what our customers actually do with it, eventually we let them attempt to fix bugs on their own.
Having been a part of this process and watching others go through it, I have to say fixing bugs is by far one of the best ways to learn a legacy codebase. Whether you dive in on your own or take an experienced guide with you, tracing through code to find a bug can give you a good grounding in how a product works. And due to the nature of bugs, you’re most likely going to be touching a different area of the code every time you fix something so you get a wide range of experience.
The best feedback however comes when you learn the side effects of your changes. The EditLive! codebase is getting better at instant feedback as we write more automated tests, but more than a few times either AJ or I have looked at a proposed fix, and said “nope that will break feature X because of unintended side effect Y”. These are the powerful bits of knowledge that only come from experience, and in most cases it’s from a customer who reported that feature X broke after we changed that exact piece of code.
If you’re a developer and you’ve never been on the technical support team of your product, I pity you. You can’t get a good feel for what customers want when you’re sitting behind your IDE listening to product managers. Only on the front lines can you hope to understand what people want to do with your product and how you can make it better.