Sure that applies to software development, but does it really apply to writing documentation? The articles currently on the developer page could be split up evenly between a team and be worked on simultaneously.
Besides, how large do you think the talent pool is of good documentation writers? I would estimate that it's actually harder to find good technical doc writers than it is to find good programmers.
1) The minimum qualifications for a good API doc writer is practical experience programming with the technology to be documented. That already narrows the field significantly. You can't just a hire a comp sci grad straight out of college.
2) Indeed, a comp sci grad straight out college probably wouldn't want the job anyway. A lot of people aspire to be programmers, because it seems cool, fun, and has excellent compensation. Not many people aspire to become doc writers as a career.
3) The compensation for doc writers is generally lower than for programmers, so if you're already an experienced programmer per 1, then why would you take a step down?
4) The natural retort is going to be, "Just pay doc writers more!" But that's not going to work for several reasons. First, the programmers will be unhappy if the doc writers are paid more than them. Second, companies don't value doc writers as much. Third, once you get off the programmer career track and write docs, it can be difficult or impossible to get back on the programmer career track if you ever want or need to leave Apple. In general, the market is not huge or lucrative.
What you tend to get for documentation writers, then, is often older programmers who are starting to experience age discrimination, finding it harder to get a programming job, so they settle for writing API documentation. But that's not a huge pool of available workers.
And as far as the "career track" aspect goes, have them keep coding part of the time and keep calling them a programmer.
It sounds like you have a reading comprehension problem?
> And as far as the "career track" aspect goes, have them keep coding part of the time and keep calling them a programmer.
1) You're missing the part where the majority of programmers don't want to be doc writers, aren't qualified to be doc writers, and aren't good at being doc writers.
2) It's not as simple as having them "keep coding part of the time", because the standards for hiring a coder are different from the standards of hiring a doc writer. Apple wouldn't necessarily hire the same person to do both. It could be a rare situation where Apple would consider the same person to be good enough for both jobs. This is like saying of an American football team, "Why not just have the quarterback play defense part of the time?"
Remember, the point of this is to produce high quality docs. Quality over quantity. Apple is already churning out low quality docs.
> Apple is already churning out low quality docs.
The article listed some stats where Apple is not churning out enough docs. So there isn't even quantity
I can see that you have no respect for the difficulty of writing good documentation.
Well that's extremely rude.
You listed objections people might have and I'm calling those objections shallow and bad.
> This is like saying of an American football team, "Why not just have the quarterback play defense part of the time?"
This is a situation where you need experience on the defense to be a good quarterback, and physical shape is irrelevant, and the quarterback is worried about permanent salary loss because other teams don't value quarterbacks. In that case it would make sense to have a single job title and have them do a mix so they stay fresh on their defense experience.
Even if the doc writer isn't the optimal programmer, consider the gap as a training expense and a way to make sure you have enough doc writers applying. If it's a bad idea then there is always the option of paying them even more to compensate for career damage.
And nowhere did I suggest making the normal programmers do the doc writing.
And the talent pool at the level of a single company is practically infinite unless you indeed introduce artificial constraints like not wanting to pay to tap into that wide pool
Hence the "Besides..."
> And the talent pool at the level of a single company is practically infinite unless you indeed introduce artificial constraints like not wanting to pay to tap into that wide pool
I just explained how that's untrue, and it feels like you completely ignored what I said.
You can't just say that Apple is "a single company" like any other company. Apple is the largest platform vendor in the world. How many other single companies have platforms like iOS, macOS, watchOS, tvOS, and now VisionOS? How many other single companies have effectively two bespoke programming languages, Swift and Objective-C, much less one? Perhaps only Google and Microsoft are comparable in their massive need for platform docs.
The world is HUUUUGE (even limiting by language), so not only can I say "a single company", I can raise it to the level of "a single tiny company", especially when it comes to such a small scale issue
> How many other single companies have platforms ... bespoke programming languages
How does it matter? There are gazillions of educated people in the world with all the skills for a couple of order of magnitudes more languages than just 2! And it's especially preposterous making this arguments after waves of layoffs in the tech sector
And you can't reject a simple solution "just pay more" with "companies don't value doc writers": that explains why they don't hire enough people/don't care about the quality of their output, not that there are some inherent talent pool limitations
I already explained how it matters: "The minimum qualifications for a good API doc writer is practical experience programming with the technology to be documented. That already narrows the field significantly."
You seem to think that it's just a trivial skill: https://news.ycombinator.com/item?id=38914104 But when you look at the Apple documentation archive, and the extensive, excellent conceptual articles, it's clear that this accomplishment required a lot of care, experience, and skill.
Besides, that's another misapplied requirement of yours: experience can be gained, it will take longer, but it's just another "takes more resources" issue, not something that narrows the field since for some reason you added that requirement before hiring, not before writing docs.
I don't think it's a trivial (that's your straw man), I just disagree that it requires rare man of mythical set of skills to accomplish to make it justifiably hard for poor Apple