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.
Science & tech enthusiast, and a nerd about all things visual arts.
Really into wed design and front-end/UX but also trying to fit into the full stack.
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.
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. :)