Live data from Hacker News

Apple Developer Documentation Is Missing

v4.chriskrycho.com

171–180 of 400 posts

Re: Apple Developer Documentation Is Missing

#171
post #141

Earlier quoted context omitted.

In Objective-C (and some other languages with ternary operators) the same can be written like this: int a = b ?: c ?: 0

That one's straight up called the Elvis Operator. I hate it when things like this get names that everyone's supposed to know and it's considered a mark against you if you've never heard it before, but I do think the name Elvis Operator is hilarious. :D

I was wondering why the funny name, and

> The name "Elvis operator" refers to the fact that when its common notation, ?:, is viewed sideways, it resembles an emoticon of Elvis Presley.

https://en.wikipedia.org/wiki/Elvis_operator

Re: Apple Developer Documentation Is Missing

#172

> Apple, if you want developers to love your platform — and you should, because good developers are your lifeblood — and if you don’t want them to flee for other platforms — and you should be worried about that, because the web is everywhere and Microsoft is coming for you — then you need to take this seriously. Adopt the mentality that has served other frameworks and languages so well: If it isn’t documented, it isn…

Most developers who are making apps for iOS are working for companies that only care about money. There is no fanaticism about it. If developers optimized for working on platforms they liked, no one would write console games.

Um, hmmm, that is exactly the opposite of my experience writing console games. Console game dev is fun because you can push the machine to the limit and know every technique you use will work across all devices since they are all the same (or close enough). PC/Mobile dev is hell compared to that. I worked at a company that did mostly console, shipped one PC game, vowed never again as the support costs were several orders of magnitude higher than console.

Re: Apple Developer Documentation Is Missing

#173
post #154

Earlier quoted context omitted.

Edit: this first paragraph is wrong, see child comment. Leaving for posterity. The second paragraph I stand by. SwiftUI is not in beta. It may be beta-quality, but they shipped it and encouraged devs to use it . Yes, it has undergone significant breaking changes since WWDC (and that's to be expected), but it's not described as beta anywhere in their docs about it. (See https://developer.apple.com/xcode/swiftui/ and h…

You are wrong. Go into the documentation viewer in Xcode and click on any page of SwiftUI documentation. SDK support is listed thusly: iOS 13.0+ Beta macOS 10.15+ Beta tvOS 13.0+ Beta watchOS 6.0+ Beta Mac Catalyst 13.0+ Beta [Edit: indentation]

I stand corrected – updating the parent accordingly as well. Thank you! (Comment about documenting stuff you're recommending people use, even experimentally, stands though.)

Re: Apple Developer Documentation Is Missing

#174
post #141

Earlier quoted context omitted.

In Objective-C (and some other languages with ternary operators) the same can be written like this: int a = b ?: c ?: 0

That one's straight up called the Elvis Operator. I hate it when things like this get names that everyone's supposed to know and it's considered a mark against you if you've never heard it before, but I do think the name Elvis Operator is hilarious. :D

[deleted]

Re: Apple Developer Documentation Is Missing

#175

Earlier quoted context omitted.

Hiring people who can pass a clever quiz without verifying if they do good work in the real world is precisely how a company ends up at the top of HN with the headline "Apple, Your Developer Documentation Is… Missing". I would argue that "how fast can someone implement this algorithm?" is a considerably less useful question to answer than "does this person document their code?" in an interview. If time is the constra…

what key macros do you setup to make jumping around in your IDE faster.

It's even worse than that really. Most of these white board tests seem to be "Have you revised this specific algorithm for your interview, and found the specific implementation we're looking for?" If you have, great. If not, rejected.

As a method of finding good candidates it feels like it must suck but so few companies are willing to actually measure their hiring effectiveness (and be open about it).

Re: Apple Developer Documentation Is Missing

#176
post #104

Earlier quoted context omitted.

To be honest, while documentation is extremely important in the real world, interviews are time-constrained, and it makes no sense to write documentation when you have 45 minutes to implement something like that.

Hiring people who can pass a clever quiz without verifying if they do good work in the real world is precisely how a company ends up at the top of HN with the headline "Apple, Your Developer Documentation Is… Missing". I would argue that "how fast can someone implement this algorithm?" is a considerably less useful question to answer than "does this person document their code?" in an interview. If time is the constra…

If this were true then the same would be posted for Microsoft, Google, Amazon etc.

There is likely no causal effect between whiteboard/algorithm interviews and poor documentation.

Re: Apple Developer Documentation Is Missing

#177

Earlier quoted context omitted.

> I'll make it clear that I'm NOT a fan of these. I am mediocre, at best, at them, as I don't come from a traditional CS background (I started as an EE). I come from a CS background and struggle with these too. The big problem I have is this performance stuff is often barely relevant to the position. You need to know the principle of a BST. Unless you're building a database working in a unique scenario, actually trav…

I wonder if the merit of these exercises is from reading the candidate's reaction to meaningless and trivial tasks. If they take it with a smile, or better yet if they spent part of their free time studying it in detail, they will make a terrific cog in the machine...

To be honest, as a part of hiring procedure, it has its merits. In an ideal world, you want to ask the candidates a problem that is well defined, and applies the tools that they might have learned in their past. This is why algorithmic problems are common - a large pool of candidates have recently finished school, they have a lot of fundamental knowledge from their experience there (and nothing else), and asking these is a way to evaluate [ how well is this problem approached ] with [ tools they should have at their disposal]. It's more about can you understand what you have learnt and use it to solve a novel thing, and less about can you balance a binary tree given 100 integer inputs. It's largely devolved in a cat and mouse game now, with candidates spending a large part of their time poring over CLRS or on Leetcode, and companies asking increasingly difficult (and serving no purpose but testing how much time was spent on practising) whiteboard questions.

Re: Apple Developer Documentation Is Missing

#178

Earlier quoted context omitted.

Ignoring dozens of repos (non-forked), and thousands of lines of testable, shipping code, is probably not helpful. I was a manager for a long time. I loved long résumés and relevant material. I was hiring expensive people to work on really important stuff, and there was no way that I wanted to rush the vetting. Also, I never gave a single test, and I think I got it right, every time.

Large companies tend to aim for standardization in the hiring process. They want apples to apples comparisons as much as possible, largely for legal reasons, but also for tracking metrics. Unfortunately, someone submitting high quality GitHub repo links doesn't fit a model where not many candidates are doing that.

Apple's hiring is not that standardized. Each team has their own process. There are some common themes, but they definitely don't all use the same tests. I've interviewed with a few teams there over the years (have ultimately turned down offers for one reason or another). I've had a pretty wide array of experiences, and incidentally, never a BST question.

I've also generally had very good experiences interviewing with them - tough but entirely reasonable questions focused directly on my expertise and the tech the team is using. One that stands out in contrast to OP's complaint was an interviewer that brought in a stack of printouts of screenshots of apps I'd worked on and used them to spark a discussion of the work I'd done on them.

OP's experience, while annoying, and not surprising, is also not universal at Apple.

Re: Apple Developer Documentation Is Missing

#179
post #111

Earlier quoted context omitted.

"Think the ternary operator, but worse" Giving the developer succinct ways to prevent program failure from unexpectedly undefined values is a feature.

"Giving the developer succinct ways to prevent program failure from unexpectedly undefined values is a feature." Most languages have had this since the 1960s. It's called the "if" clause. The ternary and nil-coalescing operators are shorthand (sugar) for an if test (or guard, in Swift). Like I said, I actually like them, but I have to be careful, when using them. I really like Swift, but it's quite possible to write…

> It's called the "if" clause.

"If" is often a statement, not an expression, so they aren't equivalent in a lot of cases. I'm not sure if this is the case in Swift, but I'm fairly certain that Swift's '?' operator also does unwrapping and propagation, similar to '?' in Rust.

Re: Apple Developer Documentation Is Missing

#180
post #78

Earlier quoted context omitted.

Android suffers a lot from quantity over quality. Classes are usually documented, but usually for a function like “setReturnVectorFlag” it’s just sets the return vector flag . Edit to add: I also work on both platforms, and I’d say iOS (along with MacOS) is usually easier to work with because the design tends to be sane and the names are fairly descriptive; whereas Android has a lot of weird and questionable design d…

> usually for a function like “setReturnVectorFlag” it’s just sets the return vector flag. Ah - the "repeat the method names with spaces in it" style of documentation. This is merely an exaggerated form of a trap that the majority of documentation falls into to some degree - documenting the "what" but neglecting the "why" or "how". It tells you the bit you can easily work out by intuition, reading the source or using…

> Ah - the "repeat the method names with spaces in it" style of documentation.

That's usually a symptom of aggressive linters enforcing the rule that every single public method must be documented. Programmers then produce useless "documentation" to shut the linters up. Utter waste of disk space.

Post reply on HN