Have you ever heard of Thomas Harriot?
How about Galileo?
Very few of us have heard of Thomas Harriot, yet there is evidence that he actually used a telescope before Gailileo did.
In August 1609 Harriot used a telescope to look at the moon. Four months later Galileo did the same thing. But Galileo shared his discovery to the world through publication. Harriot did not.
Harriot discovered Snell’s law of refraction before Snell did. Again, Harriot did not publish.
Galileo published his findings on the universe in The Starry Messenger just 10 days after making finishing his observations.
Last year Jesse James Garrett coined the word Ajax and described its use. I have heard any number of people saying that they have done this before, it isn’t really new and on and on.
But they didn’t publish the idea. They didn’t share how to do it with anybody.
And that is my point. If you come up with a new idea, and want to take credit for it, share it with the world and you will get your recognition.
Writing is the technology that brought humans to the next level in advanced technology. Civilizations that prevailed in the past were literate. They could send messages, design things and communicate their ideas through their writings. For every Leonardo da Vinci there are innumerable inventors who carried their ideas to the grave. Writing is the power that can make your ideas transcend time.
Yet writing is looked upon by so many developers as a necessary evil. Not as a technology that will bring to light your application from a backroom mystical magic creation that no one understands but you.
Writing is the same as documenting in the software world. A good design document is as valuable as the source code. It is the most efficient way to communicate how the code should work. Along with a white paper describing the project, a sequence diagram, use cases and other UML diagrams can only help clarify the ideas.
Don’t talk about “self-documenting” source code and expect a developer to understand how it is supposed to work. That is a flawed premise.
First of all, communicating by source code is very inefficient.
Secondly, if the source code is “self-documenting” that means it must be bug-free. How are you supposed to know if a behavior is a bug or not? According to the “self-documenting” source code, there can never be any bugs.
Thirdly, if you document your project, it makes it easier for you to understand how things function. The writing process brings focus on your ideas and that focus may bring refinement to the project.
Finally, as people ask you how the project works, you can use your design documents to explain. You don’t have to spend your time talking about the project; you can refer them to the design documents.
This will make you more efficient and productive, and may even bring you recognition.