Why do we code? Do we code only to satisfy the requirements of the product owner? Or do we code just so it could pass through QA? Are we just trying to get a passing grade for a class assignment? Or are we just having fun writing random stuff?
I think it is easy to forget that there are real people out there who will interact with our code when we are so deep in implementation details. Different people may interact with your code in different ways. An end user might interact with your code through the user interface, another developer may interact with your code through the API, or maybe the coworker next to you is interacting directly with your code. Whatever the means, there will always be another human in the chain interacting with the code you’ve written.
Knowing that there is another person that will interact with your code (be it user interface, API interface, or class/method interface), how do you make your code more "human friendly"?
Top comments (8)
I work with a team, I always document. Otherwise making videofeedbackr would have been a nightmare as we're all remote.
I think that's as friendly as it can get, tbh.
It never even occurred to me to use video as technical documentation. I would imagine it's quite annoying to make, tho.
Nah, about three clicks.
Don't have to save or download, I just send the link because it's browser-based. Record, stop record, send link.
Hi Martin,
I totally agree with you.
I want to know if you can offer me some work.
If you're the only person working on the project it's mostly fine to write whatever you want. But even then I would recommend writing some documentation for your code as you code.
As soon as you're working in a team you absolutely have to make sure that your code is human-readable. Other developers will hate "the person who wrote this" and will have a hard time completing their own tasks because your code wasn't documented.
And it's pretty simple. Write docs for your functions/methods, their parameters, add some comments explaining why you did what you did. The rubber duck is a great tool for identifying which parts of your code aren't so well understood.
And for the love of God, don't use
anywhen working with TypeScript.Dude, seeing any where there shouldn't be any just grinds my gears.
Trying to explain my code/interface to someone else (or a rubber duck) usually help me find what isn't easily understandable about it 😊
my code is me-friendly and me-friendly only (too lazy to make documentation)