4 ms·
I think this is unnecessarily reductive. When your day job is programming and you have strict sprint deadlines you don't have the hour or two it might take to l
by zer8k 3y ago
I think this is unnecessarily reductive. When your day job is programming and you have strict sprint deadlines you don't have the hour or two it might take to leisurely stroll through manpages. Quickness is a result of industry demand not because it's correct. But that also doesn't make the programmers "hate reading". I have never had a PM/manager/TL/etc budget "documentation reading" into sprint points. I will hazard a guess and say you haven't either. So if you're not reading manpages in your free time Google/ChatGPT/SO/whatever is usually the best option.
- baud147258 3y ago> I have never had a PM/manager/TL/etc budget "documentation reading" into sprint points. When working with new software components, usually we're able to either work into our sprints an experimentation/PoC task, that'd include reading the doc or we just include into the estimation of the development task some time to read
- pjmlp 3y agoHow do you think we used to develop software before the Internet became widespread?
- mike_hearn 3y agoI think reading documentation along with many other tasks is meant to be just budgeted into a task when planning it. You probably wouldn't write buggy code that doesn't work then say the sprint didn't have an explicit line item for debugging?