Live data from Hacker News

Apple Developer Documentation Is Missing

v4.chriskrycho.com

221–230 of 400 posts

Re: Apple Developer Documentation Is Missing

#221
post #210

Earlier quoted context omitted.

Noted the first two bits in the post . Did you read it? :) As far as SPM goes: they've got it built into Xcode at this point, and are doing WWDC sessions about it. At what point does it become "official" enough to warrant "This needs to be better" criticism? As far as "useless internet karma points": I couldn't care less. History has shown that when people make enough stink about this kind of thing, it sometimes—rare…

> Noted the first two bits in the post. Did you read it? :) Yes, I did read. Come on. However, you're not quite right. You called Swift "relatively well covered". I disagree with that and consider the Swift language documentation excellent. That's not really the same thing. I did see you mention the WWDC videos, but I think you mischaracterize the role of them. My point is, people who are interested in learning Swift…

To be clear: I've watched every SwiftUI video. They're great! They just aren't the same as docs.

As for the look: I understand the take. We obviously differ on whether it's ever appropriate to make some noise this way. For my part, when it's come my direction (as it has a couple times in the Ember ecosystem), I've appreciated it.

Re: Apple Developer Documentation Is Missing

#222
Apple payments APIs are the worst APIs I've ever worked with. They're inconsistent, badly documented, have unannounced breaking changes and contain so many gotchas it isn't funny. For example, some of the most relevant data is attached to the response but isn't officially supported and may or may not be correct.

It's not exactly fun to code up payment integrations, and so I was kind of hoping to get it over and done with. But with Apples payment APIs, we needed months of production data to figure out how to use them without shooting ourselves in the foot.

Using the API felt like interfacing with some badly configured eventually consistent MongoDB cluster that a bunch of juniors stuffed full of receipts, using the entirely wrong data model.

Re: Apple Developer Documentation Is Missing

#223
post #199

Earlier quoted context omitted.

> All family people, with decades of programming experience I might be reading into this wrong, but it almost sounds like you're saying that you only hired people who had families. Doesn't that sound a little bit discriminatory?

You are reading it wrong.

Could you clarify what the intended reading is, then?

Re: Apple Developer Documentation Is Missing

#224

A couple years ago, maybe around Swift's debut, Apple began to mark all their sample code, projects, programming guides, technical notes, etc, as deprecated and unmaintained with a header on each page stating so, and putting it all in their "Documentation Archive" [0] They've had a new push to make sure that the remaining official documentation is available in either Swift or Objective-C, but I have yet to see any at…

Along with this, they removed or not generated PDFs like they once had. This is really painful for folks that have problems with looking at a screen for an extended period. They don't even have downloadable documentation that can be read on an iPad. The lack of PDF is a real issue for me. The continued failing of example code is really painful.

Serious question (I asked because my spouse is starting to have some of these issues) - if you can read a PDF on the iPad, how is that different from reading the HTML docs on the iPad? Is it something with the layout, or is it the cognitive load of having to click a lot of links rather than having a linear layout of the text? I'm interested in learning more about this to help my spouse out!

Re: Apple Developer Documentation Is Missing

#225

Some time ago, I was contacted by Apple to apply for a job. My code is insanely well-documented. I like to think that a lot of the inspiration for my code docs comes from Apple's open codebases. Their code is exceptionally well-documented. In any case, as is usual with all employers, these days, they completely ignored the focused, relevant links that I sent them to elements of my extensive portfolio of repos, and, i…

I used to think Google and Apple were making a poor choice by doing this kind of interview, but I wonder now if it gets the results they want: they want interchangeable cogs that don't stand out too much. They want known quantities. If you're "the documentation guy" or "the security-testing girl", you've wasted time learning skills they won't utilize, since they want you to be exactly like every other developer. If d…

Leetcode is just a game that you have to play to get into these companies. I suspect that OP had other interview rounds that went poorly. There is always a chance of getting a bad interviewer, but it doesn’t often happen in every single round.

Re: Apple Developer Documentation Is Missing

#226
post #162

Earlier quoted context omitted.

Yes, but I LIKE Swift, because of all that sugar. I started off with machine language, in embedded systems. You can't get much more "raw" than that. I have been writing Swift exclusively for a long time. I speak it without an accent. It's my beauty. But I also know that you can have so much sugar you fall into a diabetic coma.

>But I also know that you can have so much sugar you fall into a diabetic coma. Exactly my feelings. Same thing here started from machine code and now doing everything else including kitchen sink

Did you guys really start from machine code or do you mean assembler?

Re: Apple Developer Documentation Is Missing

#227

Earlier quoted context omitted.

Asking the same questions also makes it easier to compare between candidates and the questions can become optimised over time to ensure they are fair and valid performance predictors. Also, it's never obvious how much someone contributed to their portfolio. Just being able to explain it doesn't mean you were the sole contributor, or the contributor at all, and it doesn't give a great indication of how you work or how…

"Also, it's never obvious how much someone contributed to their portfolio." You guys are absolutely correct about the reference questions. I can find no fault with that. However, there's absolutely no question that I'm the sole contributor to all my code. Most of my repos have only one contributor (Yours Troolie). A couple have been forked off. I do link to a number that have been turned into larger projects; with mu…

> However, there's absolutely no question that I'm the sole contributor to all my code. Most of my repos have only one contributor (Yours Troolie). A couple have been forked off.

A bad actor could easily just have someone else write the code or copy it though.

Re: Apple Developer Documentation Is Missing

#228

Some time ago, I was contacted by Apple to apply for a job. My code is insanely well-documented. I like to think that a lot of the inspiration for my code docs comes from Apple's open codebases. Their code is exceptionally well-documented. In any case, as is usual with all employers, these days, they completely ignored the focused, relevant links that I sent them to elements of my extensive portfolio of repos, and, i…

I used to think Google and Apple were making a poor choice by doing this kind of interview, but I wonder now if it gets the results they want: they want interchangeable cogs that don't stand out too much. They want known quantities. If you're "the documentation guy" or "the security-testing girl", you've wasted time learning skills they won't utilize, since they want you to be exactly like every other developer. If d…

I was at a place that had been around for 20+ years, but needed to grow fairly quickly. So they systematized their hiring process. The focus was on generalists both because a lot of their technology was written in-house (it predated the commodity, off the shelf, solutions). It used the theory of the off the shelf solutions, but often had a different name or a slight difference. But the major reason they wanted generalists, like you say, was so they could move people around as-needed.

Much of the industry was either specialists in their studies, or specialists in that they knew a specific software package. It was interesting to interview people who had very in-depth knowledge of one thing, but completely oblivious to even the basics of other areas.

Re: Apple Developer Documentation Is Missing

#229
post #183

Earlier quoted context omitted.

"Asking the same questions also makes it easier to compare between candidates and the questions can become optimised over time to ensure they are fair and valid performance predictors." I've seen this claim getting bandied about a lot lately, but I'm increasingly less convinced. You receive 10 n-dimensional vectors of programming and engineering skill, aka "applicants". You take their dot product with a ten-dimension…

The most important aspect of an interview process is that it is easy to teach. It doesn't matter if you have enough insight if you can't transfer said insight to those who will be on the floor and interview. So no assumptions about common sense of the interviewer is allowed, because common sense isn't common. So the only thing you really can do is ask objective questions or check technical skills. Thus the choice is…

"The most important aspect of an interview process is that it is easy to teach."

That basically begs the question of what I'm saying though; why should we expect that there is an "easy to teach" process that "works", for some useful definition of "works"?

Our desire for something to exist does not mean it does exist. I think a lot of the rhetoric around "fixing" interviews is making this fundamental mistake, where what is desirable is laid out, and then some process that will putatively lead to this is hypothesized, but there isn't a check done at this phase to be sure the desired characteristics can even exist.

It may be that evaluating human beings and whether they can fit into technical roles is just fundamentally hard. (I mean, when I put it that way, doesn't it sound almost impossible that it's untrue?) While acknowledging fundamental difficulty is not itself a solution, it does tend to lead one to different solutions than when the assumption is made that there must be some easy, repeatable solution.

I can sit here and wish there was some easy way to communicate how to be a full-stack engineer in 2019, but that doesn't mean that such a thing exists, and anyone trying to operate on the presumption there is is headed for the shoals at full speed. People who know such easy things don't exist may still wreck themselves but at least they aren't guaranteed headed towards the shoals.

(Or, to put in another really technical way, the machine-learning-type bias that somewhere in the representable set of interview processes there must in fact be a good solution is not necessarily true, and think there's good reason to believe it's false.)

Re: Apple Developer Documentation Is Missing

#230
post #199

Earlier quoted context omitted.

Yes. I confirm that everyone that worked on my team worked out well. Some had more challenges than others, but we got the job done. The team worked well together, and we worked with our overseas compatriots in exemplary fashion. I was very fortunate. It was a small, high-functioning, C++ team of experienced engineers. All family people, with decades of programming experience. I'm quite aware that this was a luxury. I…

> All family people, with decades of programming experience I might be reading into this wrong, but it almost sounds like you're saying that you only hired people who had families. Doesn't that sound a little bit discriminatory?

You cannot hire by not discriminating. It's by default a task that discriminates.
Post reply on HN