I’ll Remember This – Or Not: The Power of Documentation

I’ll remember it. It’s my code; I know what it does, and I understand my writing and coding style. I’ll be fine… right?

I love coding. Like, a lot. But I was a junior once too. I remember talking to seniors who really seemed to know what they were doing. They wrote their code – fast, efficient – but didn’t bother with tests or documentation.

When I started on a new project, I saw that code for the first time. My job? Ask questions until I understood what was going on. So I did. But those seniors? They didn’t remember the answers. They had no idea why they’d written things a certain way, what their logic was, or even what the code really meant.

And then… I did the same thing. I believed my code was self-documenting. I picked good names for variables and methods, I wrote a few tests. No documentation.

Big mistake.

Why You Should Write Documentation – And Why I Do Too

Help Your Future Self

Yes, you’ll remember. Just like I do? Trust me – you won’t. Save yourself (and your future you) a massive headache. Whether you’re working on a new feature or doing some refactoring, good documentation is a gift. It complements clean code, thoughtful structure, and tests.
Short on time? Been there. But you’ll lose even more time debugging later if you skip it now.

Help Newbies During Onboarding

Trainees, juniors, even seniors – everyone benefits from good onboarding. The assumption that senior devs can dive in after one team meeting is… cute.

But false.

And let’s talk about your juniors. You don’t need them? Sure, until your senior quits because your project is a mess (yep, no documentation), and suddenly no one wants to join your team.

Write documentation. Improve onboarding. Save your team and your budget.

Find Bugs Before Others Do

Bugs happen. But guess what? You can catch them sooner if you write documentation.

As I write docs, I often realize parts of my logic don’t make sense. It’s like explaining your code out loud – inconsistencies become obvious. I tweak my logic, I test, and yes, I document. It works better every time.

Be a Professional

It’s simple: the code without documentation isn’t complete.
No one cares how fast you code if no one can understand it later.

So, How Do You Write Good Documentation?

Choose Your Weapon

I work mostly in Kotlin, Java, and Python.

• Kotlin/Java? Use [Javadoc] or [KDoc].
• Python? Use [docstrings].

Pick the format that suits your environment.

What, Why, and How

If you don’t know where to start, answer three simple questions:

• What does your code do?
• Why does it do it that way?
• How should it be used?

Use AI (But Don’t Rely on It)

Use AI tools as a starting point. Let them help you get unstuck. But never copy-paste.
Writing clear documentation is a skill – and the only way to get better is to practice.

Keep It Up-to-Date and Just Long Enough

Your docs must stay current. Changed something during debugging? Update the docs.
Documentation is part of the development cycle – not an afterthought.

And yes, be brief – but not too brief. Comments like “Fix this button, it looks odd” won’t make you any friends.

Use Layers of Documentation

Your project should have multiple levels of documentation:

• Project level: README.md with setup, purpose, structure
• Module level: describe what each module does (e.g., user, auth, puzzle)
• Class/method level: include meaningful comments and examples
• Good naming: variables, methods, and test cases should be self-explanatory

Be Consistent

Confluence, internal Wikis, or shared docs – follow your team’s standards.
Stick to consistent terminology, formatting, and structure.

Conclusion

If you think you don’t need documentation… you probably need it the most.
Start small. Write something. And thank me later.