You will be judged based on your documentation

Developers become developers because they like to code. Many started coding as teenagers after school, or during the hours after their workplace. They realize how much power they can get from their IDE and their command line, and they become addicted to it.

Even when developers find that dream job where they can code all day, many keep their side projects going into the evenings and after hours. I personally know developers who continue to code on the train after they leave their office – because what else are you going to do on a train?

Coding is a way of life. It’s that simple.

Don’t miss the first TNW conference in València in less than 4 weeks!

The heart of technology comes to the heart of the Mediterranean – March 30 – 31

There’s just one little problem: coding isn’t the only part of software development.

You will also need to work with a team, attend meetings, write emails, and write documentation for your code.

And what will make or break your career in the long run isn’t the emails you’ve written or the meetings or the contributions you’ve made at meetings. It won’t even be the code you wrote, believe it or not.

The deciding factor between a career that makes a lasting impact on your business and one that doesn’t is only 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 of back-end programming and data science. Then came Python3, and everything in Python2 was outdated and didn’t work with new code.

There will always be a language, a framework, a technology that will do the job better and faster.

Or maybe it’s just trendy.

In any case, many junior developers – and that’s usually most new hires – won’t be dealing with the old languages ​​anymore.

They will rewrite your code.

Or forget it completely.

Your code does not exist in a vacuum

Even if your code is in a fairly popular language, no one will understand it just by reading that code.

Maybe you write part of the front-end of an application. But without at least some knowledge of what the backend does, no one will understand the code in depth.

And, as many developers can testify, deep understanding is crucial to maintaining code.

You can’t just add a front-end feature without thinking about back-end support for it. Or add a feature that looks nice in your app, but essentially no one cares about it.

Team members come and go – so do you

Documentation is on-boarding’s best friend.

Think about it: how many new hires has your team had over the past few years?

And how many existing team members have had the time and patience to explain every piece of code to these new hires?

Developers must ship. Most developers just don’t have the time to invest a few months into getting a new team member up and running. Your manager doesn’t care about your mentoring abilities. They want to see results in the form of code.

Documentation is the solution. Anything you can explain, you can also write down. Once written, it can help a new employee. Or two. Or a hundred.

Documentation scales. And saves time.

Besides, one day you will no longer be there to supervise new employees. You may move on to a higher position. Or you change companies. Or you are on sick leave if something happens.

Anyway, if you’re gone, your documentation will work for you.

Your documentation is your legacy.

Managers don’t look at your source code anyway

Developers who code for a living will not understand your code in depth by reading it. Your manager won’t understand it at all.

Most managers know this. That’s why they don’t read the source code.

It’s not laziness. It’s effectiveness.

Managers must decide which resources to use for which project, which team member to move where, and so on. Business decisions.

But at their core, they manage the people who create code. They manage code at a very high level.

You can’t manage code if you don’t understand anything at all. So managers read the code documentation.

Besides, if you consistently produce great documentation for your code, your manager might notice.

And give you a promotion.

How to make documentation fun

Yes, all of the reasons above are good reasons to write better documentation. But developers don’t want to write like they’re Stephen King. They want to code like they’re Bill Gates.

Documentation is that back pain that comes when you have to be happy because you just wrote great code.

However, you can make it less painful.

Usage Ongoing documentation and write down your documents while you code. Usage smart tools to write and maintain your documentation.

Only a small proportion of developers do this. But that share is rapidly increasing.

More and more developers are realizing that they need to upgrade their documentation. It’s a necessary evil.

Ongoing documentation, or the habit of contributing to your documentation whenever you make a change – no matter how small – makes the pill easier to swallow.

Famous Last Words
The road to lasting impact in the world of software is twisty and winding, and you need a bit of luck too.

If it was just about writing great code, it would be a straight road.

Documentation makes the road to success more difficult because it is a task that many developers do not enjoy.

Cut it into small pieces and document every change as you make it.

Your career will thank you.

Contents

Shreya has been with australiabusinessblog.com for 3 years, writing copy for client websites, blog posts, EDMs and other mediums to engage readers and encourage action. By collaborating with clients, our SEO manager and the wider australiabusinessblog.com, Shreya seeks to understand an audience before creating memorable, persuasive copy.