Developers become developers because they love to code. Many studied coding as teenagers after school, or after their cubicle hours. They realize how much power they can get from their IDE and their command line, and they get addicted to it.
Even when developers land their dream job where they can write code all day, many of them continue to do their side projects in the evenings and during later work hours. I personally know developers who keep coding on the train after they leave their desks – because what else would one do on the train?
Coding is a way of life. It’s that easy.
Don’t miss the first TNW conference in Valencia in less than 4 weeks!
The heart of technology comes to the heart of the Mediterranean – March 30-31
There is one small problem: Programming is not the only part of software development.
You will also have to work with a team, sit in on meetings, write emails, and write documentation for your code.
And in the long run, neither the emails you wrote nor the meetings nor the contributions you made during meetings will make or break your career. It won’t be the code you wrote, believe it or not.
The deciding factor between a career that has a lasting impact on your company and one that isn’t just one thing: your documentation.
In two years, no one will understand your source code
Languages and frameworks come and go.
Just a few years ago, Python2 was the status quo for back-end programming and data science. Then Python3 came along, and everything that was in Python2 was old and didn’t work with any new code.
There will always be some language, some framework, some technology that will do the task at hand better and faster.
Or maybe it’s more modern.
Either way, many junior developers–and these tend to be the majority of new hires–won’t be interested in legacy languages any longer.
They will rewrite your code.
or forget about it altogether.
Your code does not exist in the void
Even if your code is in a fairly popular language, no one will understand it by just reading that code.
You might be writing a front-end part of the application. But without at least some knowledge of what the background is doing, no one will understand the code in depth.
And as many developers can attest, an in-depth understanding is critical to maintaining the code.
You can’t just add a front-end feature without considering back-end support for it. Or add a feature that looks great in your app but no one cares about intrinsically.
Team members come and go – even you
Documentation is the best friend on the plane.
Think about it: How many new employees has your team hired in the last two years?
And how many existing team members have the time and patience to explain each piece of code to these new employees?
Developers need to charge. Most developers don’t have the time to invest two months on getting a new team member. Your manager is not interested in your mentoring abilities. They want to see the results in the form of code.
Documentation is the answer. Whatever you can explain you can also write. Once written, it can help a new employee. or two. or a hundred.
Documentation tables. And it saves time.
On top of that, you will never be around to instruct new hires. Perhaps you will move to a higher position. Or you will change companies. Or you will be on sick leave when something happens.
Either way, when you’re not there anymore, your documents will work for you.
Your documents are your legacy.
Managers won’t look at your source code anyway
Developers who program for a living will not deeply understand your code from reading it. Your manager will never understand anything.
Most managers know this. That’s why they didn’t read the source code.
It’s not laziness. It’s effective.
Managers need to decide which resources will be used in which project, which team member to move to, and so on. business decisions.
At their core, though, they’re managing the people who make the code. They manage the code at a very high level.
You can’t manage code if you don’t understand anything at all. So the managers read the code documentation.
Plus, if you’re consistently producing great documentation for your code, your manager might notice.
I will give you a promotion.
How to make documentation fun
Yes, all of the above reasons are good reasons to write better documentation. But the developers don’t want to write like Stephen King. They want to code like they’re Bill Gates.
Documentation is that pain in the back end that comes when you have to feel good that you just wrote great code.
However, you can make it less painful.
Use continuous documentation and write your documents while coding. Use smart tools to write and maintain your documents.
Only a small percentage of developers do this. But this percentage is increasing rapidly.
More and more developers are realizing that they need to upgrade their documentation. It is a necessary evil.
Continuous documentation, or the habit of contributing to your documentation whenever you make a change—no matter how small—makes it an easy pill to swallow.
famous last words
The road to making a lasting impact in the world of software is bumpy and bumpy, and you’ll need a share of luck, too.
If it was just a matter of writing great code, it would be a straight road.
Documentation makes the path to success more difficult because it is a task that not many developers enjoy.
Cut it into small pieces, and document each change once you’ve made it.
Your profession will thank you.