Subscribe to my email list now at http://jauyeung.net/subscribe/
Follow me on Twitter at https://twitter.com/AuMayeung
Many more articles at http...
For further actions, you may consider blocking this person and/or reporting abuse
Not so sure I agree with your comments on documentation. Sure, documentation should exist, and someone has to write it - but it probably shouldn't be a developer.
Juniors - probably don't understand the business domain enough to write good user documentation etc.
Seniors - probably write in too much technical detail for end users to be able to follow etc.
Both, should be writing code, and the time spent on documentation (and it's approvals process) detracts from what developers are paid for doing.
There is the argument for a "self documenting system" too of course - the UX should be clear enough that users don't need documentation. Who has read the user guide for "How to Google?" The backend should be fault tolerant enough that when a user gets something wrong, it's caught, and they're guided the right way. The code itself should be self-documenting, such that any junior knows what's happening just by reading it.
If you don't have a self documenting system, various types of documentation are needed - but in my opinion, it shouldn't be a developer writing them.
Good input. In a company/large team environment you're probably right, but if it's a solo project or a small team of mainly developers it's a good lesson not to skip out on I think. It also helps people who might join the team get a hang of things quicker.
If it's a bigger project, yeah, interns & juniors are often tasked with similar things if there's no one better lol.
I think tests are pretty good for documentation, so at least those can be written.
No tests, no release.
That's what CI/CD is for. :)
Nice compilation of things we need to do especially on both the doing manual testing and documentation is something I hate someone tell me they don't have much time. In writing test cases and incrementally update their documentation from scratch to save time and effort to support, maintain and upgrade a system,
I more to add on is that you might miss out is talking in technical jargons to people. As if they know how what it means. Following the "Keep It Simple Stupid" is what one should do when explaining it to a no-technical or technical person is the right way to go.
I think we can combine them with automated tests.
They serve as good documentation and reduce the burden of testing manually.
I think there still has to have some form of documentation. Definitely having automated tests helps a lot in reducing the manual testing away.
I had an ex-colleague who swears to use manual testing and he gave me the reason. That he will forget it or unable to fix it if it runs into an error. Which I just shrugged it aside as him being stuck to his ways of thinking that can be a very slippy slope.
Yea. Once he tries it, pretty sure he can't go back to testing everything manually.
In my opinion, the biggest mistake developers and not only do, is not knowing, understanding or caring where the code executes. Failing to consider those is the trademark cause for failed software.
Agreed. Never write or use code that we don't understand.
It just leads to problems later on even if it works now.
Also such a bad feeling and reading experience with the massive self promotion at the beginning.